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ABSTRACT 

Effective and timely acquisition planning is vital to the successful procurement of a 
major weapon system. However, the underlying process may not be well understood or 
defined, is labor intensive and heavily bureaucratic. Efforts to improve the planning 
function for a major weapon system traditionally focus on the people and organizational 
aspects without showing any real reductions in time or increases in productivity. New 
approaches, such as business process reengineering, now show considerable promise in 
dramatically reducing cycle times, especially when combined with information technology 
as an enabler. This paper explores the use of information technology in the development 
of an acquisition plan at a major systems command and suggests that process innovations 
of 50% or more may be possible. To accomplish this improvement, the process of 
developing an acquisition plan is redesigned using database and workflow systems as 
enablers to the process. 
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I. INTRODUCTION 



Effective planning is vital to the success of any business undertaking. This is 
especially true in the acquisition of major weapon systems within the Department of 
Defense. Even though recent reductions in statutory and regulatory requirements make 
the Federal acquisition process less complex, it is still “apparent that sound acquisition 
planning is the key to success.” [Ref. l:p. 9] 

A search of the literature indicates that prior to the Competition in Contracting Act 
(CICA) of 1984, acquisition planning in some Government agencies may have been 
performed in a sporadic and fragmented manner. Formal procedures or processes, if 
developed, may not have been followed, and if so were usually developed on a program- 
by-program basis. Planning that did occur was usually informal, and depended 
considerably on the interaction and experience of the personnel involved. This lack of a 
formal planning process may have “led to situations where the contracting officer had 
inadequate time to conduct procurement effectively.” [Ref. l:p. 9-10] 

The 1984 Competition in Contracting Act corrected the lack of formal planning, at 
least indirectly, by requiring that agencies “do a better job of planning and preparing for 
competitive procurements.” [Ref. 2:p. 81] Although procurement planning had been done 
in some form or another for at least 25 years, CICA now required its use. Congress 
expressed its belief that procuring agencies were not doing the kind of planning necessary 
to effectively manage the procurement process. [Ref. 2:p. 81] To correct this. Congress 
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directed in Title 41, U.S.C. Section 253a (a) (1) (B) and Title 10, U.S.C. Section 2305 (a) 
(1) (A) (ii) that agencies would now “use advance procurement planning.” 

The Federal Acquisition Regulation (FAR) at Part 7 defines acquisition planning as 
“the process [emphasis added] by which the efforts of all the personnel responsible for an 
acquisition are coordinated and integrated through a comprehensive plan for fulfilling the 
agency need in a timely manner, and at a reasonable cost.” The FAR requires the 
development of a comprehensive acquisition plan as soon as the agency need is 
determined. 

As a result of CICA, and its shift toward competitive procurements, acquisition 
planning now became more necessary and formalized. [Ref. 2:p. 81] Acquisition plans are 
required by FAR 7.105 to have milestones that address all of the technical, business, 
management, and other significant considerations that will control the acquisition. 
Although the FAR spells out all of the elements of an acquisition plan, nowhere does the 
FAR spell out a specific process to use in developing an acquisition plan. At best, 
acquisition planning can best be thought of as an iterative process that becomes 
increasingly more definitive as the weapon system progresses from program initiation 
through post-production support. [Ref. 3:p. 3. 3-3 .4] 

The underlying process, or processes, that drive the development of an 
acquisition plan are not well understood or defined. In a study conducted by the Logistics 
Management Institute (LMI) of several Government agencies, it found that no 
documented acquisition planning process existed prior to LMFs efforts to develop one. 
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Many organizations depended on their staffs to handle the next acquisition plan “just like 
they did the last one.” [Ref. 4:p. 378] Most often the only record or insight that existed of 
the acquisition planning process was in “the memory of the participants, particularly for 
steps at the interface between components.” The elements of an acquisition plan may be 
relatively well defined, but the process of generating, or formalizing, the acquisition plan 
may not be as well understood. [Ref 4:p 382] 

In order to begin understanding acquisition planning as a process, the term process 
must first be understood. A process is a structured and measurable set of activities 
designed to produce a specific output. Processes are centered around how things are 
done, as opposed to what is to be done, such as an acquisition plan. Typically, processes 
have a beginning, an end, and a clearly identifiable input and output. Processes cut 
through the typical hierarchical and vertical structures associated with organizations. 
“Whereas an organization’s hierarchical structure is typically a slice-in-time view of 
responsibility and reporting relationships, its process structure is a dynamic view of how 
the organization delivers value.” [Ref 30:p. 6] 

Many business processes “are characterized by a mode of operation in which work 
flows in a serial fashion from one process to another.” [Ref. 4:p. 378-379] When these 
administrative processes break down, “patches” are applied to fix the problem. Over time, 
a series of patches will most likely produce a poorly operating process. Fragmentation 
and splintering will result and further reduce the efficiency of this process. Perhaps the 
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only way to effectively correct this problem is by redesigning, or reengineering, the 
existing business process. [Ref. 4:p. 379] 

Michael Hammer and James Champy in their 1993 book. Reengineering the 
Corporation: A Manifesto for Business Revolution, defined Business Process 
Reengineering (BPR) as: 

[T]he fundamental rethinking and radical redesign of business 
processes to achieve dramatic improvements in critical, contemporary 
measures of performance such as cost, quality, service, and speed. 

Within this definition. Hammer gave four key words that provide the essence of 

reengineering. The first word, fundamental, provides the most basic notion of 

reengineering; Why do we do what we do? It takes nothing for granted, ignores what is, 

and concentrates on what should be. The second key word, radical, means getting to the 

root of the problem. In context, it means disregarding all existing procedures and 

inventing completely new ways of doing things. The third word, dramatic, means a 

quantum leap in performance, not a marginal or incremental improvement such as with 

Total Quality Management (TQM). A 50% or greater improvement, not a five or ten 

percent improvement. And the last, and most important word, processes, is used within 

reengineering to -mean a • collection - of - business activities - or • tasks • that takes -inputs and 

provides an output of value to a customer. Reengineering is different in that it does not 

focus on discrete tasks, jobs, people or structures, but on a business process as a whole. 

[Ref. 5:p. 32-36] 
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In the most basic sense, reengineering is about starting over with a blank sheet of 
paper. It is about inventing new approaches to business processes that may bear no 
resemblance to existing processes. It is not about restructuring or downsizing merely for 
the sake of cutting budgets. Nor is BPR about new ways to reorganize or eliminate 
bureaucracies. It differs from Total Quality Management (TQM) in that TQM is about 
continuous, iterative improvements approach to business processes. BPR innovates. 
Finally, BPR is not the same as automation. Automation, in many cases may only provide 
a more efficient way of performing a broken process. [Ref. 5:p. 47-49] 

Within BPR, automation is considered an enabler that fosters dramatic 
improvements in business process. However, automation of business processes has not 
produced the dramatic improvements in productivity as previously envisioned or hoped. 
Private corporations have spent billions of dollars over the last forty years to automate 
tasks with no fundamental improvement in performance. There has been a tremendous 
outlay of organizational capital on automation, usually with questionable or disappointing 
returns. [Ref. 5:p. 25] 

Much of this disappointment with technology in BPR is attributable to the 
application of automation over the existing business process found within an organization. 
Information technology (IT) sped up existing business processes, but did little, if anything, 
to change imbedded process deficiencies that the successful application of BPR would 
demand. “Automating existing process with information technology is analogous to 
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paving cow paths. Automation simply provides more efficient ways of doing the wrong 
kinds of things.” [Ref. 5:p. 48] 

Information technology has assisted the process of developing acquisition plans 
mainly through word processing, spreadsheet, and limited database applications. For 
instance, development of the Naval Sea Systems Command (NAVSEA) sponsored Master 
Acquisition Planning Program (MAPP) consolidates the over 100 plans potentially 
referenced in the typical acquisition plan. Its goal is “to improve the planning process 
through enhanced communication, more efficient use of resources, and reduced cycle 
time.” However, MAPP may have little or no effect on the underlying process that 
produces the acquisition plan. [Ref. 6:p. i-iii] 

A. RESEARCH QUESTIONS 

The primary research question is: 

How can the acquisition planning process for a major weapons system be 
reengineered to effect order-of-magnitude improvements in performance? Subsidiary 
questions would include: 

I. What are the principal elements that make up the acquisition planning process? 

H. What reengineering or process improvements have been made to the acquisition 
system and what effect have these had on acquisition planning? 

III. What has been the role of IT in these process improvement efforts and what effects 
has the introduction of IT had on the process? 
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A. What effect did the initial introduction of IT have on the acquisition 
process in terms of productivity? 

B. How has the introduction of IT into the acquisition process affected both 
personnel and organizational structures? 

C. What is the current state of IT in the acquisition planning process and what 
changes will take place in the immediate future? 

IV. What pathologies and faults remain in the current acquisition planning process and 
what technologies or redesigns can be implemented to overcome them? 

V. What steps are required to successfully implement these technologies or redesigns? 

VI. How would the employment of the BPR model change future implementations of 
IT in the acquisition planning process? 

B. RESEARCH METHOD 

Information used in the preparation of this thesis was obtained through literature 
and field research. Online library catalogs and periodical databases were searched. 
Additionally, a comprehensive search of the Internet was conducted using various search 
engines. Relevant books, articles and other documents cited as a result of these literature 
searches are in the List of References. Some of the material was brought to the 
researcher’s attention during phone conversations and interviews. 

A major system command, the Naval Air System Command (NAVAIR) was 
approached to provide a source of current and relevant information on the acquisition 
planning process. Command instructions and other published guidance was used to assess 
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the NAVAIR acquisition planning process and improvements that could be attained using 
information technology. However, it was not treated as a case study in order to critique 
NAV AIR’s efficiency in developing particular acquisition plans, its programs or their 
personnel. In reality it was chosen for two reasons. 

First, NAVAIR’ s use of a core competency approach to the management of its 
planning process was conducive to effectively allowing the studying of the process. Core 
competency requires management to think much more carefully about the firms business 
activities. [Ref. 42:p. 66] This focus on core competencies eliminates many of the 
extraneous problems associated with the poor management of people and resources. 
Second, NAVAIR is very proactive in the study and automation of acquisition processes, 
providing a fertile area for research. Combined, this allowed the researcher to effectively 
study the underlying acquisition planning process and use it as a practical input to the BPR 
analysis. 

Additional information was gathered from other organizations that develop or 
acquire acquisition planning software systems. These included systems used, or planned 
for use in the near term, by the Departments of the Navy, Air Force and Department of 
Defense (DoD). 

C. SCOPE OF THESIS RESEARCH 

The main thrust of this thesis is on the application of BPR to the process of 
developing an acquisition plan within a major system command. It also includes, for 
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background and clarification, a limited analysis of the organizational, legislative and 
personnel factors that contribute to, or affect, an acquisition plan. 

The contribution of IT to the process of developing an acquisition plan is examined 
as an integral part of the overall acquisition process, not as a stand alone factor. This 
thesis attempts to apply the BPR model with the goal of presenting a new process for 
developing acquisition plans that takes advantage of, and leverages, the power of modem 
IT. Based on the analysis using BPR, a new process for developing acquisition plans will 
be suggested for future study. 

This thesis does not look at IT from a micro level view. No new code or software 
development is anticipated, although some areas ripe for development may be suggested. 
Examples would include the use of collaborative integrated design (CID) software, 
Knowledge-Based Systems (KBS), Artificial Intelligence (AI), software agents and expert 
systems in the development of an acquisition plan. 
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H. BACKGROUND 



A. INTRODUCTION 

The Defense acquisition system is extremely complex. Literally hundreds of 
thousands of employees work within an administrative system designed to execute millions 
of contract actions each year. Major weapon systems, involving billions of dollars, push 
the envelope of technology by attempting to achieve performance levels not previously 
imagined. The combination of all these factors causes high levels of contract uncertainty 
and considerable technical risk in the developmental process for a major weapon system. 
[Ref. 7:p. 109] 

The risk represented in these inherently complex acquisitions manifests itself in all 
phases of the program or process. It is measured by the inability to achieve overall 
program goals and objectives within defined cost, schedule, and technical/performance 
constraints. The two components of this measure are the probability of failing to achieve 
a particular goal or outcome and the consequences of failing to achieve the goal or desired 
outcome. Risk management is the term applied to the act or practice of controlling risk 
within a program. It includes identifying and tracking risk drivers, developing risk 
mitigation plans and continuously assessing risk to determine how it changes over the 
course of the program. 

Given that risk is present throughout all phases of a program, failure to adequately 
manage and anticipate it can have an extremely adverse affect on a program’s success. The 
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primary method to manage and control risk is an early and comprehensive planning effort 
followed by the aggressive execution of that plan. [Ref. 8.] Within DoD this planning 
effort is partly managed by two formal documents, the acquisition strategy and the 
acquisition plan. 

B. ACQUISITION STRATEGY AND PLANNING 

The acquisition strategy provides a top level description that is used by senior 
decision makers to assess whether a program makes good business sense, effectively 
implements laws and policies, and reflects top management’s priorities. Once approved by 
the Milestone Decision Authority (MDA), the acquisition strategy provides the basis for 
more detailed planning. [Ref. 9.] 

The Program Manager (PM) is responsible for developing the acquisition strategy. 
In the most basic sense, the acquisition strategy is “the framework for planning, 
organizing, staffing, coordinating, and leading a program. It provides a master schedule 
for research, development, test, production, fielding, and other activities essential for 
program success and for formulating functional strategies and plans.” [Ref 10:p. 1-1] 
This document covers the program from initiation through post-production support and 
includes all critical events necessary for the success of the program. By its very nature, 
the acquisition strategy is a plan that evolves through an iterative process, becoming 
increasingly more defined as the program matures through its various phases. The 
acquisition strategy provides a substantial portion of the functional acquisition plan. [Ref 
3:p. 3.3-3.43 
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The acquisition plan is also the responsibility of the PM, but the actual preparation 
is performed by the Contracting Officer (CO). Acquisition plans differ from strategies in 
that they are functional, execution level oriented documents. [Ref. 10:p. 4-3] It 
coordinates and integrates planning of all functions needed to execute the acquisition 
program. The Federal Acquisition Regulation (FAR) requires acquisition planning for all 
procurement, and the Defense Federal Acquisition Regulation Supplement (DFARS) 
requires PMs to prepare written acquisition plans for most acquisitions exceeding $5 
million. [Ref. 9.] 

. i 

C. ACQUISITION PLANNING REQUIREMENTS OF FAR PART 7 

The FAR, Part 7, requires federal agencies to perform acquisition planning for all 
acquisitions. This planning should include and integrate the efforts of all personnel 
responsible for significant aspects of the acquisition with the purpose of ensuring that the 
Government fulfills its needs in the “most effective, economical, and timely manner.” 
Although it does not say a written plan should be prepared in every case, it does say that 
agency heads should establish criteria at which increasingly complex acquisitions may 
require written acquisition plans. 

Acquisition planning as envisioned by the FAR encourages acquisition planning as 
soon as the agency’s need is identified. One of the key points of the FAR is the 
requirement that the acquisition planner form a team consisting of “all those who will be 
responsible for significant aspects of the acquisition, such as contracting, fiscal, legal, and 
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technical personnel.” Additionally, this involvement must occur “early” in the planning 
process and should be done with requirements and logistics personnel. 

Along with considering the technical and logistical concerns, the written plan must 
address all of the “technical, business, management, and other significant considerations 
that will control the acquisition.” Specific contents of a plan may vary depending on the 
“nature, circumstances, and stage of the acquisition.” However, in actually writing and 
preparing the plan, the planner is required to follow and address mandatory sections of 
the FAR at Part 7 (See Appendix A). 

The written acquisition plan as prescribed by the FAR can be an inherently 
complex document. It is nominally broken down into two sections. The first section deals 
with the background and objectives of the acquisition and “considers what the 
Government is buying, how it will evaluate price and other cost factors, where it is to be 
performed, and the risk involved.” [Ref. l:p. 22] The second section, the plan of action. 
describes the steps the agency will take to procure the weapon system. 

The complexity issue arises from all of the divergent and overlapping factors laid 
out in the acquisition planning requirements of FAR Part 7. For instance, consideration 
must be given to logistics support issues throughout the life of the acquisition plan. If 
changes occur to Integrated Logistics Support plans (as invariably will occur), this input 
must be reflected in the acquisition plan if the desired results are to occur. By some 
estimates, over 100 plans are developed during the acquisition planning process for a 
major weapons system. [Ref. 11] 



14 



D. NAVY AQUISITION PLANNING REQUIREMENTS 



The Navy Acquisition Planning Guide (APG) states that the Acquisition Plan (AP) 
documents the results of -advanee -acquisition planning. It includes, usually by Fefefenee, 
other plans developed during the acquisition planning process such as the Integrated 
Logistics Support Plan (ELSP), the Test and Evaluation Master Plan (TEMP), or the Navy 
Training Plan (NTP). When approved, it represents a formal agreement between the 
acquisition Program Manager (PM), Procuring Contracting Officer (PCO), Chief of the 
Contracting Office, and the Program Executive Officer (PEO) as to how the PM will 
execute the program. Within the Department of the Navy, a written AP is required for the 
following acquisitions: [Ref. 12] 

• All ship construction programs and Service Life Extension Programs (SLEP). 

• Acquisitions for development programs estimated at $5,000,000 or more. 

• Acquisitions for production or services estimated at $30,000,000 or more for 
all years and $15,000,000 or more for any fiscal year. 

• Any other acquisition as designated by the Assistant Secretary of the Navy 
(ASN) or higher authority. 

APs are not required for procurements such as military construction, commercial items, 
spare parts, overhauls, and final buy out or one-time buys. 

1. Naval Aviation Systems Command Requirements 

At the Naval Air Systems Command, the acquisition plan is the principal document 
used by the PM for program review and oversight. As a matter of practice, the AP is 
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initially prepared at the same time that available funds and resources are identified to solve 
a particular need. Because of this, the AP is linked directly to the Future Year Defense 
Program (FYDP) and becomes the primary means to introduce the scope and magnitude 
of a particular program into the budget process. [Ref. 13:p. 2-1] 

E. SUMMARY 

Acquiring a major weapon system is an inherently complex undertaking because of 
its large dollar value and technological requirements. Because of this, considerable risk is 
present in all phases of the acquisition. The development of an acquisition strategy and 
plan is intended to lower risk by defining key elements: performance, risk, and cost. 
Acquisition plans act as vehicles to combine other functional plans into a coherent whole 
that the PM uses to manage the overall acquisition. 

A thorough search of the literature revealed that acquisition planning is 
predominately concerned with the functional and administrative aspects such as who is 
responsible for their development, policies to follow in development, and the form plans 
should take when completed. Thus, what is required to be in a formal acquisition plan or 
strategy is generally well defined. How we plan for the acquisition of a major weapon 
system is less certain and is frequently left to the discretion of those involved. The focus is 
on the product and not on the process. Although acquisition planning is defined as a 
process in the FAR, little is actually written that describes the underlying process. 
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m. IMPROVEMENTS TO THE ACQUISITION SYSTEM 



A. INTRODUCTION 

Improvements in the acquisition system have come about as a result of both 
internal and external pressures. Internally, changes that occurred in the acquisition of 
major weapon systems were driven by the growing complexity of these systems since 
World War II. Technological changes combined with increasing cost made previous 
organization methods unsuitable for managing the intricate weapon systems now 
demanded by the war fighter. This resulted in the evolution of the project management 
approach when acquiring major weapons systems. 

Externally, other forces acted to improve the acquisition system. Over the years 
Congress has periodically taken the initiative to improve or influence the acquisition of 
defense systems. Major legislative actions include the Competition in Contracting Act 
(CICA) and, more recently, the Federal Acquisition Streamlining Act (FAS A). 

Of relevance here is to what extent have changes to the acquisition system, both 
internal and external, influenced the process of planning for these acquisitions. 
Understanding of the intent of these improvements to the acquisition system may shed 
some light on where the focus has traditionally been. In some cases, changes evolved or 
were initiated that applied directly to the process. And, in other cases, the change may 
have focused more on achieving a desired outcome with little thought for the underlying 
process. 
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B. ORGANIZATIONAL IMPROVEMENTS 



As stated by Michael Hammer, “There are some differences between the private 
and public sectors, but it’s my experience that differences are much less important than 
similarities.” [Ref. 14] Most private industrial corporations are organized, for internal 
operations, along functional lines as are their Government counterparts. [Ref. 2:p. 120- 
121] The underlying cause for any differences between the two is that Government 
organizations have somewhat different goals and objectives. [Ref. 15:p. 1-1] These would 
include the fulfillment of social and economic goals and objectives such as those for 
Socially Disadvantaged and Minority Firms, Federal Prison Industries, Buy American Act, 
and Small Business Act. [Ref. 2:p. 1 and Ref. 16:pg. 8-9] 

Within the DoD slightly different procurement organization structures have 
developed in response to the rigorous demands of developing a major weapon system. To 
comprehend the difficulty of planning for an acquisition requires an understanding of the 
complex business and administrative systems prevalent in procurement organizations. 
These systems employ planning and control functions that are sometimes at odds with the 
traditional hierarchical approach found in the management of many organizations. [Ref. 

2:p. 120-121] 

1. Development of the Project Management Organization 

Since World War II the approach to acquisition management and organization has 
changed considerably. One reason has been the constantly growing change in the 
technical complexity and the sheer size of weapon systems acquisitions. As weapon 
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systems became more complex and technologically challenging, the ability of traditional 
bureaucratic organizations to coordinate and control the actions of virtually hundreds of 
other organizations and thousands of people proved to be unrealistic. [Ref. 2:p. 120] 

The principles of division of labor and hierarchical control of organizations 
appeared to be ineffective when applied to the acquisition and management of highly 
visible, complex, and costly weapon systems. When it became apparent that these 
management techniques did not possess the flexibility and robustness necessary for 
success, new management approaches were developed. [Ref. 2:p. 120-121] 

The chief change that evolved in the acquisition of weapon systems was the 
development of the Project or Program Management approach. Program management 
tends to violate traditional management structures such as lines of authority, span of 
control, unity of command, and task specialization. Under project management, a parent 
organization establishes the project and assigns the personnel. Upon completion of the 
project, the temporary organization disbands and the personnel are reabsorbed back into 
the parent organization. Program management appears to be one of the current 
approaches used in managing complex undertakings. [Ref. 2:p. 120-121] 

There are two prevalent organizational structures used in project management: the 
project organization and matrix organizations. Project organizations are more routinely 
used in laboratories and advanced development program offices. In this organization, 
project team members report directly to the project manager rather than to a functional or 
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line manager. Team members from a variety of disciplines are integrated into a single unit 
that supports one project at a time. [Ref. 17:p 22.2-22.3] 

Major weapon systems are more frequently managed in a matrix organization 
referred to as program office or system program office (SPO). In this organization 
structure, the program office is managed by a program director or a program manager 
(PM) who normally reports to a program executive officer (PEO). Under the PM are a 
number of functional areas such as contracts, logistics, and systems engineering controlled 
by division heads. The program office also includes a projects division comprised of 
project managers. Project managers may be responsible for specific subsystems, 
integration projects, or system modification efforts. They may also be responsible for 
multiple projects depending on the size of the undertaking. [Ref. 17:p. 22.2-22.3] 

2. Development of the Integrated Product Team 

Until recently, matrix organizations have been the prevalent means of managing the 
acquisition of a major weapon systems program. However, Integrated Product Teams 
(IPT) are rapidly surfacing as the primary method for controlling large undertakings. In 
the latest version of the DoD 5000. 2-R the Secretary of Defense “directed that the 
Department of Defense perform as many acquisition functions as possible, including 
oversight and review, using EPTs.” Additionally, the Secretary decreed that “IPTs 
would be composed of representatives from all appropriate functional disciplines working 
together to build successful programs and enabling decision-makers to make the right 
decision at the right time.” [Ref. 3:p. 1-7] 
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EPTs may overcome some of the more traditional problems still present in matrix 
organizations. Even though independent technical organizations such as engineering, 
testing, and procurement provide matrix support to the PM, layered functional 
management still exists. Time consuming meetings, briefings, and staffing requirements 
may slow the acquisition process and decision making. Additionally, vestiges of the 
functional organization remain, vying for limited program management office resources. 
This tends to result in the management “stovepipes” and inefficient communications, those 
things that the matrix organization originally sought to remove. [Ref. 18:p. 165] 

One result of implementing IPTs in the acquisition process is a flatter organization 
with a streamlined decision making process. A flatter organization moves decision making 
down to the lowest possible level. These benefits manifest themselves as one would 
expect — reduced development time, lower personnel cost, and improved integration of the 
finished product. [Ref. 18:p. 164] 

One inevitable problem cited with these new organizational structures is the 
conflict that arises between project managers and the vestiges of traditional organizations, 
the functional division managers. This conflict arises out of the power struggle as each of 
these managers vies for the organization’s resources. Dilemmas arise between team 
members regarding priorities, commitments and allegiances. If not dealt with in a timely 
manner, severe problems can affect the acquisition. [Ref. 17:p. 22.6] 
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c. 



HUMAN RESOURCE IMPROVEMENTS 



Since enactment of CICA in 1984, there has been an acceleration in procurement 
initiatives undertaken by Congress. [Ref. 2:p. 79] This rapidly changing environment will 
most likely require personnel who are capable of understanding and implementing those 
changes. If the acquisition workforce can not comprehend important process changes or 
their effect on the overall system, it is not likely that those processes will succeed. In 
recognition of the fact that people are the key element to the success of any process 
change, the Congress and the Department of Defense promulgated a number of changes in 
the career management of individuals involved in the acquisition process. These changes 
have included implementation of the Defense Acquisition Workforce Improvement Act 
(DAWIA), the establishment of a consortium of acquisition schools under the leadership 
of the Defense Acquisition University, and the Defense Management Review. 

1. Defense Acquisition Workforce Improvement Act 

A possibly lasting change in the management of personnel involved in the 
acquisition process has been the DAWIA. Although many studies previously conducted 
on this issue proposed changes in the management of acquisition personnel, few succeeded 
or carried the weight of change as the DAWIA. Signed into law by the President on 
November 5, 1990, it brought together improvements previously only suggested by 
studies such as the Packard Commission Report and the China Lake Demonstration 
Project. [Ref. 2:p. 107-110] 
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The DAWIA differed from previous legislative efforts in that it looked at 
underlying weaknesses in the management of acquisition programs and identified 
personnel education and training as the key. It avoided the common legislative remedy of 
adding additional layers of management and oversight to correct previous failures in the 
acquisition process. The general intent of DAWIA was to improve the acquisition 
process by strengthening and improving the professionalism of the individuals responsible 
for the process, the acquisition workforce. [Ref. 2:p. 107-110] 

The DAWIA identified many problems in human resources management within 
DoD. A principal weakness identified had to do with the short tenure of incumbent 
acquisition personnel, a lack of career incentives, the inflexibility in the current civilian 
personnel system and a lack of qualification standards for appointment to key acquisition 
positions. Congress corrected many of these shortcomings by requiring the Secretary of 
Defense to take several actions, the more significant include; (1) establish policies and 
procedures to manage the acquisition workforce, (2) the establishment of an “acquisition 
corps,” and (3) the establishment of a Defense acquisition university structure. [Ref. 2:p. 
109-110] 

Although the requirements of DAWIA were far ranging, the actual effects on the 
acquisition process are less well known. As of this writing, almost four years have passed 
since the last mandatory provision of DAWIA was enacted in 1993, yet the full effects are 
not yet known. As with many Government process improvements, little effort was 
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expended to establish the structures and mechanisms required to collect useful data and 
identify emerging trends. [Ref. 19:p. 97] 

2. The Defense Management Review (DMR) 

The Defense Management Review was a response to a presidential directive in 
National Security Review (NSR-11) to develop a plan for fully implementing the 
recommendations of the Packard Commission and the Goldwater-Nichols Defense 
Reorganization Act. The DMR examined a broad range of issues within DoD and called 
for management improvement actions in various areas. 

Within the acquisition community, the DMR highlighted the need for improving 
the human resource element. The DMR shared many of the improvements called for by 
DAWIA with regard to personnel issues. It also called for the creation of “small, high 
quality staffs” supported by strong initiatives to “reduce management layers, motivate 
personnel, consolidate functions, and refocus attention on core functions. An objective of 
achieving a 10 percent or $5 billion reduction in administrative cost was established.” 
[Ref 2:p. 112] 

The effects of the DMR, as with DAWIA, with regard to the human resources 
improvements are also unclear. Although it is a positive step, the actual results of any 
process improvements are difficult to measure. Its focus may have been more on the 
outcome than on the process itself 
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D. LEGISLATIVE IMPROVEMENTS 



In exercising its power of the sovereign, the Congress enacts various laws and 
rules affecting the acquisition system and its process. These laws are normally interpreted 
by executive agencies and promulgated in the form of regulation. Improvements in the 
acquisition process must be consistent with the framework that the Congress establishes or 
as a result of the statute enacted by Congress. Over the years Congress normally reacted 
to real or perceived problems within the acquisition process by passing a variety of new 
laws including the Competition in Contracting Act (CICA) and the Federal Acquisition 
Streamlining Act (FAS A). Both of these have had an effect on the acquisition planning 
process. 



1. Competition in Contracting Act (CICA) 

According to Sherman, the Competition in Contracting Act “deserves status as the 
keynote for government procurement processes for the foreseeable future.” Enacted into 
law as Title VII of the Spending and Reduction Act of 1984, CICA set the stage for the 
micromanagement of government procurement. CICA affected virtually all the 
participants, both private and public, involved in procurement programs. [Ref. 2:p. 79] 

Although CICA mandated many seemingly broad and encompassing changes to the 
procurement process, perhaps its most significant impact was the congressional urging 
that Federal agencies do a better job of planning and preparing for competitive 
procurements. [Ref. 2:p. 81] As Nash contends, “Acquisition planning in many agencies 
has historically been performed in a sporadic and fragmented manner. Any planning that 
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occurred was often informal and haphazard — often dependent on the personnel involved.” 
[Ref. ftp. 9-10] Through CICA, Congress expressed its belief that procuring activities 
“were not doing the kind of advanced thinking and planning necessary to achieve an 
effective and efficient procurement process. . .” where competition was believed to be the 
key. [Ref. 2:p. 81] 

The CICA requires that executive agencies “use advance procurement planning . . . 
in preparing for the procurement of property or services.” [Ref. ftp. 10] However, neither 
CICA nor subsequent legislation defines what constitutes an advance procurement plan. 1 
Federal regulatory bodies such as the Office of Federal Procurement Policy (OFPP) have 
promulgated the requirements for a formal acquisition plan in the FAR (Part 7), but these 
only spell out documentation requirements. Additionally, Congress, through CICA, urged 
Government procurement experts to find ways to simplify and streamline the existing 
processes. However, CICA itself may be at odds with this declaration in that it includes a 
significant increase in administrative requirements as well as new procedural rules. [Ref. 
2:p. 82-83] 

2. Federal Acquisition Streamlining Act (FASA) 

The Federal Acquisition Streamlining Act of 1994 introduced changes described as 
“sweeping” and “of paramount importance.” [Ref. 2:p. 93] Signed into law by President 
Clinton as a major element of his “Reinventing Government” initiative, FASA alters or 

1 

It should be noted that prior to CICA, the Aimed Services Procurement Regulation (ASPR) did require Advanced Procurement Planning, but the extent to which it 
was used is not known. 
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affects some 225 provisions of law affecting the procurement process in Government. 
Based on the work of the Packard Commission of 1986 and the Section 800 Panel Report 
chartered by Congress in 1991, FAS A introduces legislative changes that insert practical, 
result oriented policies into the acquisition process. [Ref. 2:p. 92] 

Among the more significant changes, FASA revised the traditional definition of 
what constituted commercial products or items in an attempt to exclude these from 
governmental bureaucracies and regulations. It also changed the Simplified Acquisition 
Procedures (SAP) threshold to $100,000 from $25,000 and required agencies to develop 
electronic commerce capabilities in order to retain use of these procedures in the future. 
And, it established $500,000 as the threshold for requiring cost and pricing data. [Ref. 
20:p. 15-17] 

The real question at this point is to what extent will FASA improve the acquisition 
planning process? A GAO report issued in 1996 indicates that while DoD is complying 
with a majority of FASA’s requirements, many civilian agencies may not be complying 
with the act as originally intended. [Ref. 21:p. 2-4] 

E. INFORMATION TECHNOLOGY IMPROVEMENTS 

Sherman states that, “[t]he computerization of government procurement programs 
has evolved slowly.” He goes on to say that most advances in the automation of the 
acquisition process are the result of individual effort and not the result of any significant 
agency initiatives. From a policy point of view, more effort is devoted to “procurement 
controls, ethics, policy, and audit than automation.” The adoption of information 
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technology by the government does not match the progress achieved by private industry. 
[Ref. 2:p. 131] 

Within many corporations, automated purchasing systems are integrated with 
inventory, demand forecasting, scheduling, and distribution systems. These systems, in 
most cases, far exceed what is available at most government organizations. For instance, 
at Ford Motor Company, IT was the key enabler that allowed them to revamp their parts 
procurement or acquisition process. It allowed them to reduce personnel in the 
purchasing department from 500 to 125. This quantum leap in productivity would not be 
possible without IT. [Ref. 5:p. 41-44] 

1. Information Technology in Acquisition Planning 

Within the Government acquisition environment, there seems to be a general 
paucity of data concerning the use of IT in the acquisition planning process. This 
researcher has found that searches of automated databases, the Internet and periodical 
literature for information about application of IT to the Government acquisition process in 
general yields little information. A similar search conducted on commercial systems yields 
considerably more information. 

Explanation for this occurrence may be two-fold. First, there is a tendency in 
Governmental organizations to develop automated procurement systems at a level that 
benefits top management. This is done to provide upper echelons with a comprehensive 
management information system used in its oversight function. Secondly, automated 
systems within Government were initially developed to compile statistical data as a means 
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of proving compliance with various socio-economic programs. In either case, the impetus 
to develop automated systems within the Government provided a different initial 
motivation from that of the private corporations which have most always been driven by a 
desire to increase productivity, and hence, profitability. [Ref. 2:p. 132] 

2. Survey of Current IT System Capabilities and Applications 

Only recently has the DoD begun to realize the importance of IT in the acquisition 
planning process. In January 1995, the Under Secretary of Defense for Acquisition and 
Technology (USD[A&T]) chartered an Automated Acquisition Information (AAI) 
Process Action Team (PAT) to “define a vision and build a roadmap to institutionalize an 
automated acquisition information process to provide current and comprehensive 
information ... to effectively and efficiently buy weapon systems.” This charter 
recognized the need to apply IT to the DoD acquisition processes, but what was decidedly 
unique about this PAT was its orientation across functional areas. For the first time, it 
recognized the need to integrate program management, logistics, engineering, and finance 
into the automation of the acquisition planning process. [Ref. 22:p. 26-27] 

Another area of concern recognized by the AAI PAT was the lack of a list of 
automated information software used in the acquisition process. Individual agencies often 
develop unique software in support of their particular needs when information systems 
may already exist that would satisfy that requirement. The result is the parallel and 
duplicate development of numerous automated acquisition systems within the Government 
acquisition community. To correct this deficiency, the AAI PAT recommended that the 
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Naval Air Systems Command (NAVAIR) PMA-250 collect information on all automated 
systems used in the acquisition process. [Ref. 22: p 31] 

A recent review (February 1997) of the Defense Acquisition Deskbook web site on 
the Internet confirmed NAVAIR PMA-250’s efforts to collect this data. Under a 
Software Tool Information link, there was a listing of approximately 89 different 
acquisition related software (Appendix B). This is consistent with a 1989 study conducted 
by the Logistics Management Institute that identified 76 information systems supporting 
DoD procurement organizations. [Ref. 23] 

The PMA-250 list includes over 17 functional areas such as contract management, 
program management, logistics, test and evaluation, engineering, and financial 
management. Of these, there were approximately 49 systems that describe contract 
management as one of the functional areas supported by that software. Briefly, 53 
described program management, 30 logistics and 37 financial management. 

The PMA-250 list, however, is not all inclusive and may only include DoD 
software. A search of the Internet for acquisition planning tools resulted in several hits, 
both commercial and private. Of these, the General Services Administration (GSA) Home 
Page revealed a similar undertaking to locate and canvas agencies for software used in the 
acquisition planning process. For example, the National Aeronautics and Space 
Administration (NASA) listed a system called the Acquisition Planning Expert (APEX) 
that reportedly saved over six million dollars in five years of use. And, GSA reported the 
use of a system called Transmitting Records Electronically and Quickly (TREK) that 
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reduced the number of document handoffs from 49 to 4, and reduced the days to process a 
purchase request from 36 to 14. 

3. Planned Improvements 

The previously reported information does not include planned improvements. 
Currently, the Defense Logistics Agency is undertaking the development of yet another 
acquisition related software. Known as the Standard Procurement System (SPS), this 
system is intended to replace legacy systems across the DoD and automate still existing 
manual operations. This is an inherently complex task given that DoD procurement is 
conducted at over 1500 contracting offices involving approximately 56,000 individuals. 
[Ref. 23] 

The Program Baseline Plan describes SPS as a system that will use “commercial 
software which will form the basis for an automated DoD contracting system and employ 
standard data and data transmissions within DoD and with industry.” SPS will use an 
open systems architecture with an underlying relational database and will be Electronic 
Commerce/Electronic Data Interchange (EC/EDI) capable. It will operate on a stand- 
alone Personal Computer (PC), in a network environment, or in a “megacenter,” and 
includes hardware, training, maintenance, and deployment services. The system will be 
capable of performing the full range of acquisition functions including procurement 
planning, solicitation, contract award, and contract administration. The estimated 
program cost is approximately $326 million and the life cycle cost through the year 2005 
is $3,088 billion. [Ref. 24] 
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One of the key goals of SPS is to standardize procurement processes within the 
procurement functional area of the DoD. SPS satisfies this goal by embedding existing 
procurement policies and procedures into a single automated system with a database 
shareable by other DoD users and then replacing existing and legacy systems throughout 
the DoD. By linking with other non-procurement legacy systems, such as existing 
financial systems used by the Defense Finance and Accounting Service (DFAS), SPS will 
hopefully ensure quicker and more accurate contract payments. [Ref. 23 :p. iii] 

F. SUMMARY 

Efforts at improving the acquisition process have not produced clear and easily 
discernible results. Organizational changes, such as the recent development of IPTs, may 
have only allowed acquiring agencies to keep up with rising work demands caused by the 
increasing complexity of weapon systems. Changes to personnel requirements and 
training have yet to produce any demonstrable results or improvements in the acquisition 
process. Legislative improvements have been numerous, and in some cases far reaching, 
but one cannot point to any substantial gain in productivity as a result. Various 
technological improvements to the acquisition system have been attempted, but again with 
uncertain or marginal success. 

Given that all these efforts have failed to produce dramatic improvements in the 
acquisition process, what avenues are left open? Organizational and personnel changes 
may only be capable of producing so much given their physical limitations and finite 
abilities. Legislative changes are top down approaches that many times impose more 
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requirements than they eliminate, consume considerable time, and produce unpredictable 
outcomes. 

Information technology, though often seen as a panacea, has also failed to produce 
substantial gains in productivity within Government. However, many private 
corporations, constrained by some of the same organizational and personnel problems as 
Government, have recently used IT to produce phenomenal improvements to their 
processes. The following chapter examines the role of information technology and 
suggest ways in which IT could be used for leverage to produce dramatic gains in 
productivity in the acquisition process. 
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IV. THE ROLE OF IT IN THE ACQUISITION PROCESS 



A. INTRODUCTION 

The Department of Defense planned to spend over $9 billion on Information 
Technology (IT) and related services in 1996, over a third of the total Federal IT budget 
of $26.5 billion. This does not include an estimated $24 billion to $32 billion that DoD 
will spend for software embedded in major weapon systems. [Ref. 25:p. 3,10] But since 
the Office of Management and Budget (OMB) does not collect comprehensive budget 
data on IT expenditures, the actual amount spent on IT may be unknown. Nor do 
Government agencies, including DoD, break out IT obligations as separate line items in 
budget submission. [Ref. 25:p. 3-4] However, the passage of the Information Technology 
Management Reform Act (ITMRA) may have some future effect on these problems. [Ref 
26: p. 3] 

The real question, however, is what impact has this voluminous spending had on 
improving Government operations or processes? Little, if any, according to the General 
Accounting Office (GAO). GAO states repeatedly that these information systems “cost 
millions more than expected, take longer to compete than anticipated, and fail to produce 
significant improvements in the speed, quality, or cost of federal programs.” [Ref. 26: p. 2] 
“Despite spending more than $200 billion on information management and systems in the 
last 12 years, the government has too little evidence of meaningful returns.” [Ref. 27:p 3] 
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The GAO is not alone in this assessment. The Software Technology Support Center 
(STSC) states that [Ref. 28:p. 1-1]: 

The software industry is reaching its 50 year mark, however, the 
same problems that plagued us 20 years ago still persist. DoD has had a 
distressing history of procuring elaborate, high-tech software-intensive 
weapons that do not work, cannot be relied upon, modified, or maintained. 

Many of these over budget, overdue programs have been canceled after 
reaching full-scale production with millions of dollars wasted, and not a 
single unit reaching the warfighters’ hands. With virtually every 
acquisition snafu, the software component can be isolated as the prime 
source of our dilemmas. 

This problem is not unique to the DoD or even the Federal Government. 
Currently, GAO reports that 11 federal agencies have significant problems with 
information management systems under development and has labeled them as “high-risk.” 
These information systems are defined as high-risk “because they are especially vulnerable 
to waste, fraud, abuse and mismanagement, and were potentially costing the government 
billions of dollars without clear returns.” [Ref. 25:pl2] The systems identified are key 
elements of mission critical components that together represent a multibillion dollar 
investment of scarce Government resources. One example, DoD’s Corporate Information 
Management (CIM) initiative, is cited as consuming over $3 billion annually without 
demonstrating any real benefit. [Ref. 25:p. 12-14] 



B. RECURING FAILURES IN THE ACQUISITION OF IT 

A more prominent, and consistent theme in the acquisition of IT is the repeated 
failures that occur over time. As early as 1979, GAO reported that of the custom built 
Management Information Systems (MIS) under development for governmental agencies. 
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more than 60% had schedule overruns, over 50% had cost overruns, more than 45% of 
the software could not be used for its intended purpose, and 29% was never even 
delivered. Normally had such problems been publicly scrutinized, there would be an 
intense effort to correct the problem. However, over the next 15 years the problem did 
not go away. As shown in Table 1 (adapted from the STSC), these problems continue 
through to the present. [Ref. 28:p. 1.3 - 1.6] 
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GAO REPORT 


REPORT FINDING 


Contracting for Computer Software Development: serious 
Problems Require Management Attention to Avoid Wasting 
Additional Millions 

November 9, 1979 
(FGMSD-80-4) 


Analysis of custom-built MIS systems (163 contractors and 1 13 
Government personnel surveyed) produced the following results: 

• +60% of contracts had schedule overruns 

• +5 0% of contracts had cost overruns 

• +45% of software was never delivered 

• +1 9% of software had to be reworked to be used 

• -3% of software had to be modified to be used 

• -2% of software was unusable as delivered 


Sergeant York: Concerns About the Army’s Accelerated 
Acquisition Strategy 

May 1986 

(GAO/NSIAD-86-89) 


• 64 (of planned 614) units delivered and subsequently 
scrapped 

• FOT&E results showed significant performance shortfalls 

• Cost and schedule overruns projected if government 
demanded required functionality 

• $1.8 billion lost 

• Program canceled 


Navy Decision to Terminate its Standard Automated Financial 
System f 

March 1989 
(GAO/IMTEC-89-37) 


• $446.5 million (99..9%) projected cost overrun 

• 5 year projected schedule overrun 

• $230 million lost 

• Program canceled 


Embedded Computer Systems: Significant Software Problems 
on C-17 Must Be Addressed 
May 1992 

(GAO/IMTEC-92-48) 


• 2 years behind schedule (as of March 1 992) 

• $1.5 billion cost overrun 

• Software size/complexity underestimated 

• MilStds waived for contractor with limited software 
experience 

• Shortcuts taken on software testing and software 
supportability issues 


Software Challenges In Mission Critical DoD Systems 

December 24, 1992 

(GAO/IMTEC-93-13) 


15 major systems studied had the following common problems: 

• Poor software engineering concepts, methods, and practices 
used 

• Proceeded despite serious problems 

• Requirements were ill-defined and unstable 

• Architectures were inflexible 

• Security requirements not met 

• Poor testing methods and procedures used 

• No systems-level integration testing performed 


Attach W'arning: Status of the Cheyenne Mountain Upgrade 

Program 

September 1994 

(GAO/AIMD-94-175) 


• 8 years behind schedule (at time of report) 

• $792 million over budget (at time of report) 

• 11 years projected schedule slip 

• $896 million projected budget overrun 

• $22 million/year additional costs for continued 
operation/maintenance of old system 


Comanche Helicopter: Testing Needs to be Completed Prior 
to Production Decisions 

May 1995 

(G AO/NSI AD-95- 1 57FS) 


• Cost tripled in 10 years (from $12. 1 million in 1985 to $34.4 
million in 1995, 185% cost increase) 

• Software development and testing problems 

• Required performance has been decreased by 7 4% 



Table 1 - GAO Reports on DoD Software Failures 
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In all fairness, these failures in the acquisition of IT are not strictly a DoD, or even 
a Government, problem. A study conducted by IBM of 24 leading companies that were 
developing large, software intensive systems, all suffered similar problems. Of these 
commercial and state government entities, 55% had cost overruns, 68% had schedule 
overruns and 88% had to be redesigned to be useable. Similarly, a third of all large-scale 
IT programs are canceled and three quarters are operational failures. Table 2 lists some 
major non-military IT acquisition failures. [Ref. 29:p. 88-89] 



Year 


Project 


Results 


1980s 


International Telegraph & Telephone 
4 switching systems 


• 40,000 function point system 

• $500 million lost 

• Canceled 


1987 


California Department of Motor 
Automated Vehicle/Driver License 
System 


• 3 (5,000 function point size) 

• $30 million lost 

• Canceled 


1989 


State of Washington 
Automated Social Service Caseworker 
System 


• 7 years to build 

• Failed to meet use needs 

• $20 million lost 

• Canceled 


1992 


American Airlines 
Flight Booking System 


• $165 million lost 

• Canceled 



Table 2 - Major Non-Military Software Acquisition Failures 
The preceding discussion may lead to the erroneous belief that all IT acquisitions 



are failures. Several programs, including both Government and commercial, are IT 
success stories. These include the IT portions of the Air Force’s F-22 Advanced Tactical 
Fighter Program and the Boeing Corporation’s 777 passenger airplane. Additionally, 
many companies successfully implement IT in their companies with dramatic 
improvements in productivity and quality standards. [Ref. 28:p. 23-30] The real question 
is — what defines and separates these organizations from others that failed? 
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c. 



IT TOOLS AND THE ACQUISITION PLANNING PROCESS 



Over the last 12 years the Federal Government has spent over $200 billion on 
information technology trying to correct efficiency problems. As previously discussed, the 
results are disappointing and continue to this day. But what causes this failure when 
government tries to implement information technology to improve its processes? Michael 
Hammer provides a very succinct and powerful observation about how IT should be 
applied: [Ref. 5:p. 83] 

A company that cannot change the way it thinks about information 
technology cannot reengineer. A company that equates technology with 
automation cannot reengineer. A company that looks for problems first 
and then seeks technology solutions for them cannot reengineer. 

The solution within an organization begins with first understanding the capabilities 

of information technology. This understanding need not be in depth or extreme, but rather 

a generic understanding of what tools a particular technology or application brings to the 

process table. All this understanding must do is establish a connection between a process 

objective and the IT tool that will enable its accomplishment. What is most important to 

remember about information technology is that it is a “means of solving business 

problems, not technologies looking for uses.” [Ref. 30:p. 55] 

The Federal Government may now just be realizing this lesson. Recent legislative 

efforts including the Paperwork Reduction Act and the Clinger-Cohen Act of 1996 

emphasize the meeting of agency goals through the effective use of IT. The Clinger- 

Cohen Act: [Ref. 31:p. 9] 

[EJxplicitly requires agency heads to analyze the mission of their 
organizations, benchmark and assess the performance of their business 
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processes and, based on this analysis, redesign their mission-related and 
administrative processes (as appropriate) before making significant 
investments in information technology to support those missions. In plain 
terms, agencies should maximize the potential of technology to improve 
performance, rather than simply automating inefficient processes. 

The real influence of information technology on the acquisition planning process 

potentially lies in its “disruptive power.” Leveraging this power requires that long 

established, traditional rules about how work is done be broken. This “breaking of the 

rules” allows individuals to begin to think inductively about how to apply technology 

during the reengineering process. Only then can these long standing work rules, on which 

the underlying process was built, be changed to take advantage of the full power of IT. 

Breaking the old rules creates the possibility for new ways of working and with that 

reengineering can begin. [Ref.5:p. 91] 

Information technology is the essential enabler to reengineering because it allows 
business processes to be redesigned. Merely throwing computers and software at an 
existing process does not constitute reengineering. Many times automation only 
reinforces old, often outdated, ways of doing business. Nothing new was created. If what 
was being done was wrong in the past, it is now being done wrong even faster. This, 
combined with the inherent complexity of the existing business process, is a certain recipe 
for failure. In fact, the misuse of technology may actually block any anticipated 
improvements in performance and reinforce old ways of thinking and undesirable 
behavioral patterns. If we take it as a given that IT is misapplied to business processes, 
then how is this corrected? [Ref. 5:p. 83-84] 
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Hammer provides eight key examples of how to improve business processes with 
technology. Although not all inclusive, the elements in these examples break existing 
ways of looking at information technology. Some examples of these technologies are: 

• Shared databases 

• Expert systems 

• Telecommunications networks 

• Decision support tools 

• Wireless data communications and portable computers 

• Interactive video disk 

• Automatic identification and tracking technology 

• High performance computing. 

None of these technologies are new or startling. But if used correctly, they are the 
enablers that foster process innovation. It is the critical element in creating a new way of 
viewing an existing process. [Ref. 5:p. 92-99] 

1. Shared Databases 

A considerable portion of modem day business processes are a reflection of pre- 
automation paper “shuffling” techniques. The structure of many business processes was 
originally developed around the file folder. Information was captured on paper and 
distribution limited to those who possessed the folder. It was thought that copying 
machines would solve this problem but they probably exacerbated it by creating multiple 
copies of different versions of the same file. [Ref. 5:p. 92] 
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Another result is that many business processes tend to be structured in a sequential 
nature. Information gets passed from one individual to the next, with the first individual 
failing to see what later edits accomplished. Information technology did not solve this 
problem for most. Word processors replaced typewriters, but the paper trail remained. 
The implicit rule is that information can appear in only one place at one time. [Ref.5 :p. 
92] 

An example of this may be Navy acquisition plans. The Navy Acquisition Planning 
Guide (APG) specifies that “[t]he AP shall be limited to 25 pages. . . “ and that this page 
limit . . is to be exceeded only in exceptional cases.” The approximately 100 or more 
program plans (Appendix C) that are incorporated into the AP are done by reference only. 
These additional plans are maintained apart from the AP. In no one place can the whole 
acquisition plan be viewed. [Ref. 3 2] 

This is very interesting when it is considered that the APG states that the . . AP 
defines the structure of the program throughout its acquisition cycle.” It also states that 
“[acquisition planning is the process by which the resources and efforts of key personnel 
responsible for the acquisition are coordinated and integrated through a comprehensive 
plan . . .” Given this preamble, and the actual makeup of the plan, it is questionable if the 
two can ever be reconciled to achieve the goal of . . fulfilling the agency need in an 
effective and timely manner, and at a reasonable cost.” [Ref. 32] 

However, information technology could potentially change this approach. Shared 
databases allow information to appear in as many places as it is needed, simultaneously. 
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Any number of people can share this information. Acquisition plans need not incorporate, 
by reference, other plans. Nor do the plans have to be subdivided. The database itself 
may now become the plan. Instead of the process being fragmented by territorial and 
inter-organizational competition, all efforts are directed at the same goal, maintaining the 
acquisition plan as it was originally intended, as a coordination and integration tool. 

2. Expert Systems 

Expert systems use business rules and problem solving techniques along with 

databases to evaluate situations or determine courses of action. These systems are 

1 ' . ’ 1 

designed specifically to capture and apply consistently the expertise of a human specialist 
in a particular field. Expert systems are usually very powerful, but limited in their scope of 
application. Examples currently in use are medical diagnosis, manufacturing quality 
control and financial management. [Ref. 33:p. 494] 

Many existing information systems may have expert systems imbedded in them as 
part of a transaction processing system or it may be as simple as a terminal where users 
query the system for answers. At the heart of expert systems is a database of rules called a 
knowledge base. These are typically a set of instructions stated in an “IF-THEN” format. 
For example, it might say; If the price is under $2,500, then check to see if a credit card 
was used to buy the item. [Ref. 33 :p. 494-495] 

Expert systems first became widely available in the 1980’s. At that time, most 
considered them primarily as a means of replacing costly and sophisticated experts with 
cheap machines. However, that reality did not come to be. What did transpire was that it 
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allows relatively unskilled employees to now operate at nearly the level of the highly 
trained expert. What this implies is that one generalist supported by expert systems can 
potentially do the work of many specialists. Now, instead of having several individuals 
each trained to do a specific function, one individual, called a case worker, can accomplish 
all the functions. 

At first, this may not seem like a major accomplishment, but consider what 
happens in a highly sequential administrative process. Previously, each worker 
accomplished one part and then passed it to the next person to accomplish their part. Any 
one who has dealt with a bureaucracy knows that each step adds considerable time to the 
process. If at any point work must be rerouted back in the chain, it becomes even longer. 
Each handoff or error adds even more time to the process. [Ref.5:p. 92] 

The above description substantially illustrates the acquisition planning process for 
a major weapon system. Many of the improvements discussed in Chapter III alleviated 
some of the delays and bureaucracies associated with the acquisition process, but none 
have dramatically increased the productivity of the process. New project management 
organizations, IPTs, legislation, and numerous other efforts have been attempted, but none 
as of yet have resulted in a significant improvement in procurement lead times. Some have 
made coordination easier, provided better visibility over projects, or even brought better 
people to the existing process, but none have had the impact that the application of expert 
systems could provide. 
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Expert systems have the potential to dramatically reduce the time element 
associated with acquisition planning by eliminating handoffs, delays and errors that cause 
rework. A single “case worker” could manage an entire acquisition plan backed up by an 
expert system and a database. This case worker would be responsible to the PM for the 
entire acquisition planning process, from beginning to end. Less time or effort would be 
expended on passing plans back and forth, going to endless meetings, and doing another 
iteration of a plan that is already out of date. 

3. Decision Support Tools 

A technology closely related to expert systems is Decision Support Systems 
(DSS). Decision support systems, like expert systems, are designed to assist and support 
the user in the decision process, except the DSS is used in situations where the decision 
process is relatively unstructured and only part of the information needed is structured in 
advance. The significance of the DSS is that it allows the structuring of the problem by 
providing needed information, much like advanced help programs in commercial software 
programs. The difference though is that DSS may, because of the nature of the problems 
it is used in, require the system to retrieve and process data from several files and 
databases. It may also use information provided online by individual decision makers in 
the decision process. 

Information requested from a DSS are not presented in pre-formatted reports. 
Instead, each query generates its own unique output in a format determined by the 
recipients at the time of need. Typically, queries to the DSS are structured as questions 
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such as, “How will changing the requirement from 400 aircraft to 380 affect the overall 
price of the program?” As can be seen from this simple question, the ability to query the 
system makes it possible to model very complex problems with many inter-related issues. 
[Ref. 33 :p. 487-488] 

One of the appurtenances of the industrial age in modern organization is 
hierarchical decision making. This exists because workers are expected to do only one job 
and not think or make decisions about it. All decisions are referred up the ladder because 
managers, with their broader views, are the only ones that have the perspective necessary 
to make informed decisions. However, it is costly, especially within Government, to retain 
decision making authority at higher levels. [Ref. 5:p. 95-96] 

In a memo by the Under Secretary of Defense (Acquisition and Technology), Dr. 
Paul Kaminski stated that “[u]nnecessary layers of review should be eliminated and the 
decision making authority maintained at a lower level more familiar with the details of the 
acquisition.” [Ref. 34] This statement suggests that decisions should be made at the 
lowest level consistent with regulation. However, the empowerment of individuals to 
make decisions cannot be achieved only by conferring the authority to make decisions. It 
must also be accompanied with the information necessary to make those decisions. 

Modem DSS combined with database technology can provide information 
previously only available to higher level managers. Lower level personnel, properly 
trained, and employing easy to use analysis and modeling tools can make sophisticated 
decisions in support of the planning process. This capability allows decision making to be 
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retained at the lowest level possible. Decisions are made much quicker and are resolved 
when they appear in the process, not when they are noticed by higher management. [Ref. 
5:p. 95-96] 

4. Electronic Commerce/Electronic Data Interchange (EC/EDI) 

EC/EDI is a form of electronic communications that allows trading partners to 
exchange business transactions, such as purchase orders, in a form that can be readily 
processed by application software. Approximately one third of all business documents 
(invoices, payments, etc.) are transmitted by EC/EDI. One of the advantages inherent in 
EC/EDI is its ability to reduce the time needed to complete business transactions and to 
obtain the goods and services an organization requires. [Ref. 33 :p. 372] 

Within the Government, EC/EDI is becoming increasingly important. FASA 
provided an incentive for all procuring agencies to start using EC/EDI by raising the 
ceiling for purchases allowed under small purchase rules to $100,000 from $25,000. 
However, FASA provides a lower, interim threshold of $50,000 premised on whether 
agencies can verify that they are performing 75% of their contracting actions using 
EC/EDI methods. [Ref. 39:p. 19] 

By itself, EC/EDI may contribute little to improving the acquisition planning 
process. While it may provide more opportunities to increase efficiency in small purchase 
scenarios, in larger transactions it may become less important. It may still prove useful in 
coordinating acquisition planning over geographically dispersed sites and in the 
identification of potential sources of supply. However, the real innovation that is possible 
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with EC/EDI is in combining it with other process changes that lead up to the electronic 
transaction. [Ref. 30:p. 60-61] 

5. Work Flow Systems 

A relatively new appearance in information technology is the workflow system. 
Workflow systems take the paper forms and documents an organization uses in its day-to- 
day business processes and automates them using IT. By doing this, it captures the 
policies and procedures of the business into electronic forms that can then be filled, 
processed, authorized, and routed by various workers. Workflow automates the flow of 
information within the business or organization. [Ref. 35:p. vii] 

Initially, workflow systems were developed for converting paper documents to 
electronic form with scanning systems and then either storing them for later retrieval or 
transmitting them electronically with rudimentary e-mail systems. It was thought this 
would lead to a “paperless” environment. What actually occurred was that information 
generated on paper often exist simultaneously in electronic media, leading to the 
proliferation of more paper. [Ref. 35:p 214-215] 

The new generation of highly sophisticated workflow systems have similar goals, 
but the starting point, assumptions and impacts are entirely different. Early workflow 
systems attempted to automate existing paper-based business processes, there was no 
attempt to review the underlying process itself. Modem day workflow still has some of 
the concerns associated with imaging, but now the focus is on redesigning the process 
before implementing workflow systems. Workflow systems are tools that may allow 
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reengineering to take place, but it is not an inherent solution to business process problems. 
Rather, a business process should be evaluated and workflow technology inserted only if it 
brings about the desired change or improvement in that process. [Ref. 35:p. 209] 

Within the acquisition planning process, the use of workflow systems is not clear. 
A review of systems being used indicates that some packages may have this capability 
because of the underlying commercial software that is used. For instance, the Master 
Acquisition Planning Program (MAPP) may have workflow capability because it utilizes 
Microsoft Word as the underlying software. [Ref. 6] Word provides a basic routing 
capability that when combined with e-mail allows the originator to control the process that 
the document goes through. [Ref. 36:p. 329] 

Recent literature now suggests the use of workflow systems as a means of 
reengineering a part of the acquisition process, specifically the development of Request for 
Proposals (RFP). As envisioned, the RFP process would be supported by a workflow 
system combined with a shared database. There, work documents would be indexed and 
stored for retrieval and transmitted using an electronic communication such as e-mail to 
various workers involved in the RFP process. [Ref. 37:p. 92] 

What really makes this a robust and vital workflow scheme is its definition and 
control over the RFP process. “[T]he sequence of steps and agents involved in a process 
is generally enumerated beforehand, and used to automatically route work to the proper 
agent, when the work is required to be completed.” [Ref. 37:p. 92] Additionally, 
templates are available “that describe the overall flow of work in a process, along with on- 
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line process “help” and reference information (e.g., regulations, contract clauses, etc.).” 
[Ref. 37:p. 92] This technology is readily available commercially and easily adaptable to 
Government use. However, it is expensive and requires an investment in personnel 
training. None the less, the decision has been made to invest in this technology by some 
Government organizations. [Ref. 37:p. 92-93] 

D. SUMMARY 

The Federal Government’s investment in Information Technology is, and has been, 
nothing less than staggering by any estimate. The yield on this investment is questionable 
at best. Over a third of all information technology projects are never delivered. Those 
that are delivered will likely be over schedule and over budget. And, of those that are 
delivered, many are unusable for their intended purposes and require considerable redesign 
to be useful. 

At least part of this information technology crisis may be a result of how agencies 
view technology. Many see IT as a way to automate existing processes and never 
question this assumption. Others fail to recognize the solutions that IT presents or to take 
advantage of what this could do change long standing administrative processes. 
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V. PATHOLOGIES OF THE ACQUISITION PLANNING PROCESS 



A. INTRODUCTION 

In the last few years, there has been an increasing demand for a smaller 
Government that provides improved services at a lower cost. Making Government more 
effective and efficient has become a national issue. [Ref. 26:p. 2] Part of the problem is 
that many of the largest Federal agencies “find themselves encumbered with structures and 
processes, aimed at the demands of earlier times, and designed before modem information 
and communications technology came into being.” [Ref. 38:p. 6] If this is true, then the 
current acquisition process may have some of these pervasive and systemic problems, or 
pathologies, that can be easily identified. 

B. PATHOLOGIES IN THE ACQUISITON PLANNING PROCESS 

In describing opportunities to use IT during process innovation, Davenport 
identifies several pathologies that are present in existing business processes. His 
discussion is premised on the basis that before a process is redesigned, it must be 
understood what effect IT can have on the process and where this effect is felt the most. 
In other words, what underlying symptom would benefit the most from the intelligent 
application of IT. [Ref. 30:p. 50] 
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1 . 



Labor and Paper Intensive Activities 



Perhaps one of the more recognized benefits of automation is its ability to 
eliminate or reduce human labor. Although this element is more frequently seen with the 
automation of manufacturing processes, it is also associated with administrative processes 
as well. However, in administrative and service environments, processes are frequently, if 
not routinely, defined by the existing document flow. The introduction of IT, at a 
minimum, provides the opportunity to remove the paper from the process by employing 
work flow tools that define the paths an electronic document takes through the process. 
This in turn may significantly reduce the need for some human labor at every step and 
increase productivity. [Ref. 30:p. 51] 

Another benefit of the impact of IT on the process is the structure it lends to that 
process. Regardless of whether the administrative process is efficient or not, it is now 
probable that automation will cause it to be done the same way every time. The process is 
now better defined with less handoffs and passing of documents. [Ref. 30:p. 51] 

Within the acquisition process, program managers are facing a challenge of 
maintaining high levels of service to customers while simultaneously increasing staff 
productivity. As previously seen in Chapter III, “. . . changes to the acquisition process 
alone have not gone far enough to raise staff productivity. Increasingly, program 
managers must turn to technology to help solve the problem.” [Ref. 39:p. 19] 

Even acquisition processes that are currently considered well managed may still be 
too labor intensive and paper based. A recent study of the Request for Proposal (RFP) 
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process by Nissen concluded that “the baseline RFP process represents a labor-intensive, 
linear sequence of manual, paper-based activities that are interspersed between numerous 
handoffs and reviews.” [Ref. 37:p. 91] 

2. Capturing Information 

Not only can IT reduce or eliminate human labor from a process, it can also 
augment the effort. If IT is exploited to capture information about process performance, 
then that information can be analyzed to determine what improvements or changes are 
required to optimize performance. This analysis can be done by individuals involved in 
managing the process or may be done by other IT tools such as expert or decision support 
systems. [Ref. 30:p. 51] 

As shown in previous chapters, many procurement organizations seldom use 
information about process to improve productivity. The result of this is that information, 
or metrics, critical to the effective operation of contracting organizations is not available. 
Generally, these organizations rely upon “their staffs to use their memories to handle the 
next acquisition ‘just like they did the last one.” [Ref. 4:p. 378] The overall effect is that 
management and acquisition process owners may lack the information necessary to 
improve the quality, timeliness, efficiency and effectiveness of their operations. [Ref. 4:p. 
378] 

At NAVAIR, a review of AP and related procurement process instructions yields 
little information about automated systems used to capture information about the process. 
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Mention is made of four different automated systems associated with the procurement 
process at NAVAIR. These are summarized in Table 3: 



System 


Description 


Acquisition 

Instruction 


PM Information System 
(PMIS) 


Management Information System 


NAVAIR Acquisition 
Guide 


Program Acquisition 
Information System 
(PAID) 


Text and graphics image retrieval 
system of Navy/DoD acquisition 
documents. 


NAVAIR Acquisition 
Guide 


Acquisition Tracking 
System (ATS) 


Automated database of 
NAVAIR/PEO AC AT programs 
and their milestone dates. 


NAVAIR Acquisition 
Guide 


Acquisition Document 
Processing and Tracking 
System (Bar Code 
System) 


Tracks draft APs through Phase II 
review. 


Acquisition Plans 

NAVAIRINST 

4200.36 



Table 3 - AP Related Systems 



Of interest is that most, if not all of these systems, capture very little information about the 
structure of the acquisition process. Information is collected on the overall time a 
program take to complete (PMIS), or where a document is in the review chain (Bar Code 
System), but none appear to manage or help direct the flow of the process. 



3. Sequential Processes 

One of the primary benefits of defining a given process is that the flow can better 
be examined for opportunities to reduce sequential paths. Within predominately 
administrative systems, IT can significantly reduce cycle time and substantially increase 
productivity by allowing some previously sequential steps to be performed in parallel. It 
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also makes it easier to identify bottlenecks created by sequential work flows and provides 
a means for reconfiguring around these bottlenecks. [Ref. 30:p. 52] 

Since “most administrative systems are characterized by a mode of operation in 
which work flows in a serial fashion. . . ,” it is likely that many acquisition processes suffer 
from this same problem. [Ref. 4:p. 378-379] Given this understanding, it becomes more 
clear why IT often does not produce the large productivity increases that were originally 
anticipated. Many government contracting organizations “attempt productivity 
advancements through investments in technology without examining the basic interoffice 
communications processes. Senior leadership is left questioning the value of new 
technology following marginal increases in productivity. If the ‘paper process’ is broken 
before technology insertion, the ‘paperless process’ wall also be broken.” [Ref. 39:p. 22] 

4. Analysis of Information 

As previously noted, expert systems and DSS are having a considerable impact on 
the analysis of information. IT can now support the decision making process in ways not 
widely available even ten years ago. Numerous private corporations are now routinely 
using expert systems to make decisions ranging from whether to extend credit to a 
customer to what any given customer should pay for insurance. Many are also using the 
power of these systems to collect, analyze and distribute information to key management 
personnel. Many are reporting that managers’ understanding of the business are 
substantially improved and a dramatic reduction in time spent on routine meetings. [Ref. 
30:p. 52-53] 
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Based on the information in Table 3, it appears to the researcher that little analysis 
is done by any expert system or DSS. Nowhere in the relevant instructions does it discuss 
the application of information provided by such an automated system. Nor does it instruct 
PMs or PEOs to collect such information for analysis by any system. [Refs. 46,47,48] 

5. Database Integration 

One of the more critical aspects of IT on processes is its ability to integrate 
information. In the future, it may become increasingly difficult to radically improve 
process performance for tasks that are highly segmented. One of the reasons these tasks 
remain segmented is that information on various processes are stored in several databases 
throughout an organization. This splitting of process information throughout the 
organization precludes anything but incremental improvements in processes because of the 
complexity of dealing with all those databases. Organizations that opt for more 
conservative approaches, that are incremental in nature, may find themselves increasingly 
behind when competing with others who have achieved radical redesign of processes. 
[Ref. 30:p. 53-54] 

This problem of integration applies to the acquisition planning process as well. As 
shown in Table 3, numerous databases are used just in the AP process. And, as was 
previously noted in Chapter III, over 80 types of acquisition software are currently in use 
within DoD. In fact, several of these may be in use in the same office. As has been 
observed, “[t]he typical program office has a mixture of automation technologies.” [Ref. 
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39:p. 20] To add to this problem, many program offices may not have established 
procedures for managing all of these IT resources effectively. [Ref. 39:p. 20] 

6. Expert Knowledge of Processes 

One of the greatest assets of any organization is the knowledge and experience of 
the people who make up that organization. However, many times the knowledge and 
experience these personnel possess is not well managed. Part of the reason is that 
common wisdom may hold that knowledge intensive activities are not viewed as 
processes. However, a number of private corporations are capturing this knowledge using 
IT and making it readily available to the rest of the company. The goal of this undertaking 
is to make expert knowledge readily available to the entire company. [Ref. 30:p. 54] 

Within DoD, this intellectual vision may be taking shape. The Defense Acquisition 
Deskbook (DAD) is “an automated reference tool providing the full complement of 
acquisition information ‘at the fingertips’ of the acquisition profession.” [Ref. 40:p. 40] 
The DAD provides information on several levels. First it provides current mandatory 
DoD regulations that must be followed. Then it provides discretionary information and 
guidance where mandatory regulation leaves off It also provides an information structure 
where innovative practices, practical advice and lessons learned can be reviewed. Finally, 
it will stay up-to-date in the future by linking directly to the DAD web page. [Ref. 40: p. 
40-42] 
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c. 



SUMMARY 



The business processes in many organizations have evolved over time. Many of 
these broke down the process into discrete tasks so that the paperwork aspects could be 
more easily managed. The introduction of rudimentary IT did not improve performance, 
and may actually have hurt it, because it was added over the existing paper based process. 

Within the acquisition planning process, as with most administrative systems, the 
file folder has driven the development of many processes. The result is that most of the 
processes tend to be highly sequential in nature and repetitious. Information must be sent 
through the sequence over and over again for all individuals to have a chance to perform 
their edit. It also has limited the size and complexity of documents. Many are split into 
several individual folders or files when in reality it would make more sense to combine and 
integrate them. 

Another problem has been the inability of administrative systems to capture the 
knowledge and expertise of its members, to help them make decisions about it, or the 
sharing of this information with other administrative systems. Regulations and instructions 
attempt to do this but are only as good as the human memory. Organization innovations 
such as EPTs and matrix organizations may have only helped marginally. Decision making 
is still retained at higher levels, even while that higher level exhorts decisions to be made 
at the lower levels. 

Recent developments in information technology over the last several years added 
new capabilities that need to be revisited with respect to administrative processes. In the 
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strictly paper environment, information was limited in how it could be manually distributed 
and copied. The introduction of databases allows information to be available in several 
places at the same time. Expert systems and decision support systems change the way in 
which the information can be analyzed and decisions made. Workflow packages can 
overview and help define key document processes. 

These changes in technology require that the acquisition planning process must be 
looked at anew. What previously made sense from an organizational point of view may no 
longer work. In fact, the misapplication of these technologies may prevent the 
fundamental changes that are required to achieve dramatic improvements in the acquisition 
planning process. 

All of the above points to an acquisition planning system that is still highly 
bureaucratic, plagued by paper and still highly sequential even in the best of organizations. 
For example, the Naval Air Systems Command (NAVAIR), a premier contracting 
organization, devotes one publication of well over 300 pages to document the RFP 
process as it currently exists. [Ref. 13:p. i] However, an extensive review by the 
researcher reveals that only 3 out of 21 chapters (26 of 300 plus pages) deal even 
nominally with the process. The vast majority of this publication explains, block by block, 
how to fill out all of the paperwork required to support the RFP. 

No amount of training on this publication could substantially improve the RFP 
process. No matter how well written or organized, this publication could not materially 
affect the process other than to document it at a given point in time. To achieve order-of- 
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magnitude improvements, it is necessary to reengineer this process using information 
technology as the essential enabler. 
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VL REDESIGNING THE ACQUISITION PLANNING PROCESS 



A. INTRODUCTION 

The primary goal of the Department of Defense is maintaining a strong national 
defense. To achieve that goal the DoD must maintain a strong business operation that is 
capable of effectively and efficiently supporting the warfighter. Acquisition reform is a 
key link in this support issue. Placing innovative and technologically superior weapons in 
the hands of that warfighter, within an austere and shrinking Federal budget, will be an 
extremely daunting task. 

Accomplishing this task will require new approaches. Dr. William Perry, former 
Secretary of Defense, in a memorandum dated 14 September 1994, remarked that “[t]he 
private sector has found that attacking business-process cycle times is a powerful weapon 
in its reengineering arsenal which generates more efficient processes, greater product 
quality and improved organizations for less cost.” Dr. Perry was convinced that focusing 
on cycle time reductions would result in “substantial gains in . . . reducing infrastructure, 
streamlining and improving customer service.” To accomplish this reduction in cycle time, 
Dr. Perry challenged the Military Departments to reduce cycle time “by at least 50 percent 
by the year 2000.” [Ref. 41] 

But, as was seen in Chapter III, various attempts to improve the acquisition 
process have not produced substantial or definite results. These resorts to “business as 
usual” may not prove effective in the developing austere fiscal environment. Nor has 
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information technology alone, as described in Chapter IV, proven to be the “silver bullet” 
needed to achieve the substantial gains in productivity currently being sought. The 
pathologies associated with the acquisition process, as presented in Chapter V, are still 
prevalent and among us. 

However, if we are still intent on radically improving the acquisition process (a 
50% improvement in cycle times appears to be radical), then we must attempt new 
approaches. It is the point of this paper to suggest that redesigning the acquisition 
planning process to take advantage of the enabling power of information technology is at 
least part of this productivity problem. It is understood that IT, in and of itself, cannot 
change the process alone. Other human and organizational factors will have to be 
considered. But an understanding of the existing acquisition process may suggest avenues 
for the introduction of IT into that process. [Ref. 30:p. 17] 

B. DEFINING THE EXISTING ACQUISITION PLANNING PROCESS 

Several writers on Business Process Reengineering (BPR) have expressed the 
importance of understanding existing processes before designing a new one. [Ref. 4, 5, 30, 
35] Some may argue that the essence of reengineering is starting over with a clean sheet 
of paper so as not to be hampered by preconceived assumptions. However, Davenport 
provides four basic reasons for defining an existing process before designing a new one. 
[Ref. 30:p. 137] 

First, the very act of defining the process serves to stimulate understanding and 
communication among the participants of the redesign. It provides a common ground that 
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all can agree upon as a starting point. This can become particularly important when the 
process is relatively unstructured or when individuals find it difficult to even view their 
work as a process. Secondly, in most complex organizations, such as the DoD, there may 
be simply no other way to migrate to a new process without defining and understanding 
the existing process. [Ref. 30:p. 137- 138] 

Third, understanding the existing problems in a process can ensure that they are 
not repeated in the redesign process. This has routinely happened with the automation of 
an existing process that had not been sufficiently defined (hence, “paving the cowpaths”). 
Not realizing that the existing process is highly sequential may result in the same after 
redesign. As a corollary, endemic problems may frequently go unnoticed until the entire 
process is thoroughly studied. Defining the process will most likely identify pathologies 
not previously understood or noticed. [Ref. 30:p. 138] 

And, most critically, understanding and defining the current process will provide a 
measure against which the redesigned process can be valued. The existing process allows 
the collection of data for a baseline against which to measure the redesign objective. For 
example, in the acquisition process this would be a time measure of the Procurement 
Administrative Lead Time (PALT) before and after redesign. [Ref. 30:p. 138] 

1. Federal Acquisition Processes 

To begin to understand the existing acquisition planning process for a major 
weapon system, the researcher first looked at the guidance provided by policy or 
procedure. The Office of Management and Budget (OMB) Circular A- 109 provides the 
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basic policy to be followed by executive branch agencies in the acquisition of a major 
program. In setting the acquisition policy, it only defines “the rules or guidelines that 
express the limits within which action should occur.” [Ref. 42. p. 4] OMB does not 
specify any process, or procedure, for the acquisition of a weapon system; it only sets 
broad policy requirement within which agencies must act. [Ref. 43] 

The FAR, at Parts 7 and 34, begins many of its discussions on acquisition planning 
with procedures 2 . Part 34 “describes acquisition policies and procedures [emphasis 
added] for use in acquiring major systems consistent with OMB Circular No. A- 109.” 
Although Part 34 directs agencies to “establish written procedures” for the acquisition of 
major weapon systems, it does little in the way of actually presenting a defined process for 
the acquisition of those system. At best, it is a policy document in that it provides limits 
within which program managers and contracting officers should act. FAR Part 34 also 
directs the program manager to prepare an Acquisition Plan (AP) in accordance with Part 
7. 

The acquisition planning as defined by the FAR at Part 7 is a “process by which the 
efforts of all personnel responsible for an acquisition are coordinated and integrated 
through a comprehensive plan for fulfilling the agency need in a timely manner and at a 
reasonable cost.” But in the actual delineating of procedure (Section 7.104, General 

2 

Before going any farther it may be useful to differentiate between process and procedure. The American Heritage Dictionary defines a process 
as a “series of actions, changes, or functions bringing about a result” It similarly defines procedure as a “series of steps taken to accomplish an 
end.” As can be seen from the definitions, both could be used interchangeably. For the purposes of this research, both are considered essentially 
the same, differentiated only in that a procedure could be considered a part of a larger process. 
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Procedures), it only states three actual steps a planner need take; 1) form a team, 2) 
consult with requirements or logistics personnel, 3) coordinate and secure concurrence 
with the contracting officer. Other than that it does not provide any procedures or 
processes in developing a plan. What it does provide is policy guidance on the content of 
the AP. 



2. DoD Acquisition Processes 

Within the DoD, the DoD Directive 5000 series provides policy and procedures 
for the acquisition of major weapon systems. The March 15, 1996 update broke the DoD 
5000 into two parts while “significantly reducing] the length and complexity.” DoD 
Directive 5000.1 is a discretionary document specifically directed at providing “general 
principles to guide all defense acquisition programs.” As such, it is strictly a policy 
document and differs from the DoD Directive 5000. 2R which “establishes mandatory 
procedures” for major weapon system programs. 

Part 1 of the DoD 5000. 2R provides an overall acquisition management process 
for the DoD. It defines in broad, overall phases the process a weapon system would take 
from the determination of a need through the disposal of the system. Follow on parts of 
the DoD 5000.2R, though entitled Program Definition, Program Structure, and Program 
Design, provide more on policy issues than the actual process. 

However, much of this may be by design. The DoD 5000. 1 enjoins “Program 
Managers and other participants in the defense acquisition process” to turn to the Defense 
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Acquisition Deskbook (DAD) for “assistance in implementing guiding principles and 
mandatory procedures.” 

The DAD is currently managed by the Joint Program Office (JPO) located at 
Wright-Patterson Air Force Base in Ohio. The DAD is a two part automated tool of DoD 
acquisition information. A reference library contains the FAR, DFARS and DoD 5000 
series documents along with every supporting document or statute. The information 
structure contains discretionary guidance accessed via the topic or the process. [Ref. 40: p. 
41] 

The process portion of the DAD provides information on the actual steps in the 
acquisition process. This process information can be accessed via graphical interface in a 
“point and click” mode. Information on the process flow is numbered according to steps 
and the level of refinement. For example, process information is initially broken down into 
four steps numbered 1.1 through 1.4 as shown in Figure 1. 




Figure 1- DAD Acquisition Process 
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Each subsequent block can then be broken down farther to define the process 
below it. Under the block labeled 1.2 in Figure 1, Plan Acquisition and Management 
Strategies, several more blocks then define the next steps. The following steps are then 
laid out sequentially: 

1.2.1 Develop Management Strategy 

1.2.2 Develop Acquisition Strategy 

1.2.3 Determine Program Baseline 

1 .2.4 Establish Risk Management Plan 

1.2.5 Document Required Program Information 

1.2.6 Review and Approve Plans and Resources 

After this point, in addition to being sequential, the diagram is setup so that every 
step after the first one (1.2.1) flows into every step after it (1.2.2, 1.2.3, 1.2.4, etc.). 
Because of this interconnection between every step, the flowchart loses some of its ability 
to portray the actual process except in the broadest sense. This pattern is repeated down 
to three or four levels under each basic step. However, it is still very much a macro 
overview of the acquisition process and does not substantially define the acquisition 
planning process. [Ref. 44] 

3. Naval Air Systems Command Acquisition Processes 

The Naval Air Systems Command (NAVAIR) in 1993 managed approximately 
17.3 billion dollars in contracts distributed in over 200 programs. NAVAIR employs over 
47,000 military and civilian personnel and is currently headquartered in Washington, DC. 
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Additionally, it is located at 18 major technology and engineering centers, test and 
evaluation facilities, depots, and logistics support activities nationwide. Its primary 
mission is to deliver and support aircraft and related systems which can be operated, 
based, and sustained at sea. Life cycle support is provided for: [Ref. 45] 

• Carrier and other air capable ship based aircraft and systems. 

• Integrated air antisubmarine warfare and antisurface warfare mission systems. 

• Marine expeditionary forces aviation systems. 

• Maritime air launched and strike weapons. 

• Training systems for aircrew and maintenance personnel. 

The acquisition process for the development, production and support of these 
weapon systems is extremely complex and lengthy. To manage this process, NAVAIR 
provides its program managers with several sources of guidance. The NAVAIR 
Acquisition Guide (AG) is designed to provide “corporate management with a single 
consolidated overview of the major internal NAVAIR acquisition processes.” [Ref. 46:p. 
1] As such it attempts to consolidate in one document all the activities, regulatory 
guidance, and documentation requirements needed in assisting acquisition managers to 
plan ahead. It is felt that the need for “program managers, particularly new managers, to 
know the process and sequence of events and average time to complete events is essential 
for planning their programs. . .” [Ref. 46: p. 1] Additionally, it states very succinctly the 
motivation behind this focus on process: 

In addition, corporate management, by seeing the entire process, 

can focus on better ways to manage that process by minimizing the 

number of program reviews, maximizing parallel vice serial 
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documentation reviews, establishing time limits for each part of the 

acquisition process, and providing a feedback system for performance 

measurement against established time standards. 

The acquisition process at NAVAIR is broken down into several subprocesses. 
These processes include: 

1. Program Initiation process. 

2. Milestone Review/ Approval process. 

3. Program Authorization process. 

4. Procurement process. 

Of these, the procurement process is most relevant to this research. In general, it 
interfaces the program initiation process, is an integral part of the Milestone 
Review/ Approval process, and includes the program authorization process. As can be 
seen from the flow chart in Appendix D, the procurement process begins with the 
identification of a requirement and generally ends with the release of a solicitation. Within 
the procurement process is the development of the Acquisition Plan (AP). [Ref. 47: 
enclosure (1)] 

The NAVAIR AG defines the AP as the “principal document for in-depth program 
planning, review, and oversight.” [Ref. 46:p. 28] In support of this requirement, 
NAVAIR issued a separate instruction, NAVAIR Instruction 4200.36 of 26 January 1994 
to provide guidance on the preparation of APs. As shown by the flow chart in Appendix 
E, it also provides a macro overview of the actual process necessary for the preparation of 
the AP. The AP process, as shown, is divided into two major phases. [Ref. 48] 
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In Phase I, the PM designates an AP Action Officer and an AP Preparation Team 
that will prepare the draft AP for review. This team consists of a minimum of eight 
personnel from most of the functional areas within the NAVAIR organization such as 
contracting, engineering, business-financial management, training and so forth. It is their 
responsibility to coordinate the input for each section of the AP from the various 
functional codes within NAVAIR. Below this level, the process is not broken down 
further. In Phase II, the completed draft AP is sent back out for extensive review by a 
minimum of 27 different functional areas within NAVAIR. Again, how the review process 
flows is not shown in the literature. However, it does suggest that both reviews are 
conducted by individuals who then return their comments to Action Officer who 
incorporates comments as received. [Ref. 48:p. 5-7, enclosure (5)] 

This review is conducted in a strictly paper mode. Numerous copies are dispersed 
throughout the organization for review and comment as required by instruction. To 
control the flow of paper, an automated bar code system named the Acquisition Document 
Processing and Tracking System (Bar Code System) is used. This system provides 
“couriers to hand deliver draft copies of unclassified AP’s to those codes required to 
review and comment . . . plus any additional codes that the acquisition manager wants to 
have involved in the AP review.” [Ref. 48 :p. 7] 

At the end of Phase H, comments are reviewed and resolved by the PM. In some 
cases, major issues may surface and require resolution at a higher level. If all issues are 
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resolved at the PM level, the AP is approved and signed by the PM, PCO, Assistant 
Commander for Contracts, and the Program Executive Officer (PEO). [Ref. 48:p. 7-8] 

The time frame for each step varies. As Table 4 shows, the development, review 
and approval of the AP requires a minimum of 108 days to complete and can go to greater 
than 163 days. [Ref. 46:p. 28] 



Step 


Days 


Process 


1 


15 


PM establishes AP Preparation Team 


2 


45 


Team develops draft AP 


3 


20-75+ 


Formal review process 


4 


5 


PM resolves review comments (PEO Programs) 


5 


5 


APEO reviews for format and policy compliance 


6 


5 


PM and PCO sign 


7 


5 


AIR-2.0 Signs (Contracts) 


8 


8 


AIR- 1.0 (Plans and Policies) or PEO approves AP 




108-163+ 


Total time required for AP process 



Table 4 - AP Process Time Table 



Given that APs must be complete before contract award, this process could potentially 
add a considerable amount of time to the acquisition process. When the average time 
from identification of a requirement to contract award is 403 days [Ref. 46:p.32], this time 
of 108 days or greater becomes a more significant part of the entire acquisition process. 

Some redesigns of the process have been initiated by NAVAIR. As part of a 
Management Plan developed by the Contracts Competency (AIR-2.0), the AP process 
was reviewed. Changes included removal of the requirement for strict compliance with 
the AP document format, only requiring that it meet the requirements set forth in the FAR 
and DFARS. It also allows PMs to use other program documents such as the Acquisition 
Strategy Document (ASD) to fulfill the acquisition planning requirement. It also removes 
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some minor, internal, administrative requirements. However, the basic process is 
essentially the same. [Ref. 49] 

C. REDESIGNING THE ACQUISITION PLANNING PROCESS 

Given the above definition of the acquisition planning process at NAVA®, a 
number of questions must be asked and answered during the redesign process. If it is 
agreed that the preparation and review of an AP is a highly sequential, paper based, people 
intensive process, then what IT tools could be brought to the table to improve the 
process? Which part of the process is most ripe for these technological improvements? 
And finally, should the redesign be innovative and completely new, or an improvement to 
the existing process? 

First, a review of the AP process shown in Table 4 and Appendix E indicates that 
Phase I and Phase II of the process, up to review and approval, shows that most of the 
time involved in the development of the AP are in the first three steps (80 to 135 days). 
This would seem to be a productive area to concentrate redesign efforts. If the time 
required for these three steps were reduced by 50%, time for the preparation of an AP 
would fall to 68 to 95 days. This also seems like a productive area to start in because of 
the considerable paper work involved and the high level of human labor and interaction 
(meetings, conferences, etc.) required. 

As stated in previous chapters, IT can provide some of the leverage needed to 
improve processes. Some technology is currently being used in the process. Some, such 
as the Bar Code System, are used to manually track paper documents through the review 
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process. Word processors and spreadsheets are no doubt used throughout the process as 
well. Other systems are alluded to such as the Program Acquisition Information Database 
(PAID). PAID is a text and graphic retrieval system of select Navy and DoD documents 
used in the acquisition process. [Ref. 46:p. 2] Some systems, such as the Acquisition 
Tracking System (ATS), are used to track weapon systems programs and their respective 
milestone dates. [Ref. 46 :p 21] Still others, such as the Program Managers Information 
System (PMIS), are management information systems used to provide oversight data. 
There is strikingly little information in the AP publications and instructions on any other 
automated system used in this process. 

What IT tools could be used in the AP process? Table 5 considers the key IT 
tools from above and what effect each potentially could have on the AP process. Note 
that a considerable amount of the effect is the potential reduction in time. Other effects 
include: 



• Reduction in management oversight 

• Improved process control by management 

• Better decision making. 



Information Technology 


Step 


Shared 

Database 


Expert 

System 


Decision 

Support 


Work Flow 
Systems 


1 


Maintain database 
of available 
personnel for task; 
Team exist 
‘Virtually” 

Effect: Reduce time. 


Suggest personnel 
capabilities needed for 
particular AP 
development. 

Effect: Better team 


None suggested 


None suggested. 


2 


Database becomes 
AP; All personnel 
involved view AP 


Evaluates AP under 
development; 
Reduce number of 


Provide what if 
scenarios for 
management 


Define AP document 
flow; provide electronic 
document control and 
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simultaneously 
during development 

Effect: Reduce time . 


people involved in 
AP; eliminate 
handoffs; Caseworker. 
Effect: Better AP. 


evaluation; reduce or 
eliminate hierarchical 
decision making. 
Effect :B UterDecision. 


routing; readily 
available. 

Effect: Control Process 


3 


Allow concurrent 
viewing as AP 
developed; may 
eliminate step 3 
entirely. 

Effect: Reduce time. 


Same as above, may 
eliminate step 3. 

Effect: Reduce time. 


Inject management 
control in decision 
making process. 

Effect: Increased 
management control. 


Same as above; may 
eliminate step 3. 


4 


Eliminate or 
significantly reduce 
step 4 to 1 day. 

Effect: Reduce time. 


Same as above, may 
eliminate step 4. 

Effect: Reduce time. 


Same as above; may 
eliminate step 4. 

Effect: Reduce time. 


Same as above, may 
eliminate step 4. 

Effect: Reduce time. 


5 


Eliminate step 5. 
Effect: Reduce time. 


Eliminates step 5. 
Effect: Reduce time. 


Eliminates step 5. 
Effect: Reduce time. 


None suggested. 


6 


Reduces to 1 day. 


Reduce to 1 day. 


None suggested. 


None suggested. 


7 


Reduce or eliminate. 


Reduce or eliminate. 


None suggested. 


None suggested. 


8 


Reduce or eliminate. 


None suggested. 


None suggested. 


None suggested. 



Table 5 - Effect of IT on AP Process 



Given this information on IT, what would the redesigned AP process now look 
like? The estimates summarized in Table 6 assume that a shared database and a workflow 
system are implemented to redesign the current process. Expert systems and decision 
support systems (DSS) could also innovate the process, but in order to keep the redesign 
simpler and based on current, readily available technology, these technologies are 
excluded in the present study. Once the database and workflow systems have been 
implemented, it may be prudent to reconsider these other technologies. This will also 
dramatize the point that the correct application of IT can have considerably more effect 
than the application that has traditionally been used such as with NAV AIR’s Bar Code 
System for tracking paper shuffles during the AP process. 



Steps 


Days 


Process 


1 


1 


PM establishes AP Preparation Team 


2.0 


45 


Team develops draft AP 
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2.1 


0 


Concurrent formal review of draft as developed 


2.2 


0 


Concurrent PM resolution of review comments as raised 


2.3 


0 


Concurrent APEO review for format and policy compliance 
Note: step may be eliminated with expert system 


3.0 


1 


Concurrent signatures electronically 




47 


Total time required for AP process 



Table 6 - Redesigned AP Process 



In the first step, it is assumed that if personnel information is available within a 
combined database, 15 days would no longer be necessary to establish the team. 
Functional area managers would release or obligate their personnel based on managed 
workloads kept in the shared database. In the second step, it is assumed that developing 
the draft would occur essentially as it is done now. What is different is that because of the 
sharing of information via the database, approval could essentially occur as the AP is 
written. Reviewers would be able to see the AP as team members are drafting it. As the 
reviewers become more sophisticated in the use of work flow systems, the process time 
may drop further as the process itself becomes more visible to the participants. 

It should be clear from this redesign that we are not just simply introducing IT into 
a broken process (i.e., “paving the cowpaths”). Rather, we are redesigning the process for 
operation in an IT environment. 

D. PROTOTYPING AND IMPLEMENTING THE REDESIGN 

The previously discussed redesign may, or may not, be a plausible solution to 
reducing the total time required to develop an AP. A radical change to the acquisition 
planning process based solely on the above analysis may not provide an acceptable level of 
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risk for most managers. A way to mitigate this risk would be through the development of 
a prototype. Prototyping is an acceptable method to simulate and test the operation of a 
new process and central to the “re-invention lab” concept. Davenport defines it as “an 
iterative process in which the fit between new process structure, information technology, 
and organization is refined and re-refined.” [Ref. 30:p. 156] It is analogous of a scientific 
experiment performed to validate a hypothesis. 

From an organizational aspect, it would be a small scale version that replicates the 
intended process to check the validity of the design. Given the nature of the intended 
change in the AP process, it would be only prudent to first test the process redesign. This 
is especially important because of the sometimes unintended consequences that occur with 
the implementation of new IT. Also, prototyping is essentially a learning activity. What 
was constructed on paper may lack a certain reality when implemented in person. By 
prototyping, lessons can be learned from mistakes in a controlled environment. Many 
iterations may be required to perfect a redesign in this manner. [Ref. 30:p. 156-157] 

Perhaps the most important effect to consider is on the personnel in the 
organization. In more than one occasion, both within and outside of government, 
organizations have mandated the implementation of a new system without a consideration 
on the people involved. The technology may have been flawless, the plan superb, but the 
process redesign failed to provide the desired results. Much of this is a failure to consider 
the fit of technology to the people within the organization. Destroying or disrupting social 
interaction by confining everyone to a computer cubicle may not produced the desired 
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results even if it should have worked on paper. Prototyping may overcome this, gradually 
reshaping the organizational environment or allow for a revising of the technology 
involved. [Ref. 30:p. 156-157] It may also highlight new needs in terms of personnel 
skills, education, and training as well as organizational changes. 

E. SUMMARY 

Radical changes are needed to achieve the level of performance that will be 
demanded in the future. Many personnel and organizational innovations have been tried 
but have failed to achieve large, demonstrable returns. Process improvements, often 
ignored, are once again becoming the focal point for decreasing cycle times to meet new 
demands on Government organizations. 

Redesigning a process demands an in depth analysis and definition of that process. 
This is a learning exercise that informs and communicates much about the process under 
study. It is a necessary part of the redesign effort in that it prevents the recurrence of 
problems that reengineering seeks to eliminate. 

Most of what is written in the form of regulation is concerned with policy over 
procedure or process. This sets the boundaries within which agencies must act, but not 
how they accomplish the acquisition. Only recently, via the automated Defense 
Acquisition Deskbook, has the DoD began to place more emphasis on the process and not 
on policy. 

The acquisition planning process at NAVAIR is a relatively mature and well 
developed process, but it is not well documented. It is heavily sequential, paper based. 
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and personnel intensive. Little effective use of IT has been implemented. Systems 
currently in place are more concerned with automating existing processes than using them 
to leverage the process. Internal redesign efforts focus more on changing the existing 
process through eliminating paper requirements. Overall gains from these efforts were 
most likely marginal at best. 

The redesign described above considered the use of IT to dramatically improve the 
process. To mitigate risk, the technology used was limited to the readily available, off the 
shelf variety. Startling new technologies will not necessarily make a process more 
effective or efficient. In many cases, lower risk, existing technologies with a proven track 
record, well applied in the design of a process, can have a considerable impact on the 
productivity of an organization. 

At NAVAIR, as with many other Government organizations, technology is viewed 
in a completely deductive mode. What are we doing now that could be done faster with 
technology? This approach will provide some improvements, but only marginal at best. A 
more productive line of reasoning is inductive; how can the process be redesigned to take 
advantage of technology’s power? 

NAVAIR, as may be representative of most Government organizations, applied 
technology to track where the location is of a piece of paper in a manual routing process. 
It treated the information as inventory to be accounted for in its location. At best, the AP 
draft is accounted for now, no matter where it is located. A better application of 
technology would be to eliminate the paper and develop a common database combined 
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with a workflow scheme that is an electronic, or “virtual” plan. This requires a different 
way of viewing the process. One way looks at it as a process that is broken down into its 
smallest parts. The other way looks at it in the whole for a solution. 
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VH. RECOMMENDATIONS AND CONCLUSIONS 



A. INTRODUCTION 

In doing this thesis, the researcher has tried to avoid the overuse of terms like 
reengineering. Business Process Reengineering (BPR), re-invention, acquisition reform, or 
any number of other terms associated with these very recent management initiatives. This 
was done to avoid connotations similar to what Total Quality Management (TQM) 
inspires in some minds. However, these are only the most recent in a spate of 
management techniques spawned over the years. Management by objective, operations 
research, management by walking around (MBWA), risk assessment and financial analysis 
all fall in this genre. 

Whatever the value of the above listed techniques, most, if not all, brought some 
useful element or tool to the table depending on the time and the place. It is the same with 
BPR. The difference in this case is that Hammer and Champy were able to bring attention 
to BPR at a time when its potential could be most fully realized — when the maturity of 
Information Technology (IT) could finally start to have a substantial impact on processes. 
But the “reinvention” of this process focus is an idea whose time has come. 

B. RECOMMENDATIONS 

The following recommendations are a suggested list of actions that many 
acquisition organizations could take to reengineer their procurement functions. It is not 
proffered as a cookbook approach to making reengineering a workable solution. Instead, 
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it is submitted as a possible course of action that could, if properly applied, significantly 
reduce process times and radically improve organizational performance. 

1. Identify the Process 

Acquisition organizations should first leant to correctly identify and study business 
processes. Too narrowly or widely defining a process reduces the likelihood of success. 
The research at hand investigated the acquisition planning process. Going to a higher 
level than this would have meant dealing with a process that was too large and unwieldy. 
Any smaller and the benefits may begin to decrease. Additionally, the opportunity for 
introducing IT into the process is less clear at either end of the extremes. The literature 
suggest that somewhere between 10 and 20 key processes exist within any organization. 
[Ref. 30:p. 28] However, based on the researcher’s experience and observations, many 
organizations place process identification at the lowest priority. 

Throughout the research effort, there was strikingly little information available on 
organizations that had studied their key processes. Only three articles even remotely 
spoke to process analysis within organizations. The researcher can only assume that this is 
indicative of its consideration on a whole. Some progress in this area may be indicated. 
The Defense Acquisition Deskbook (DAD) now focuses considerably on the process 
initiative. Some management literature the researcher reviewed from the Naval Air 
Systems Command (NAVAIR) showed a recent, and renewed, interest in process 
definition and analysis. 
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2 . 



Additional Technologies 



In proposing a redesign to NAV AIR’s acquisition planning process, the researcher 
purposely avoided proposing the use of expert systems and decision support systems 
(DSS). The reason, in addition to what was stated, was to avoid “assuming solutions” to 
problems. The use of readily available IT made the solution plausible using today’s 
technology. However, expert systems and DSS are both mature technologies that have 
been around for a number of years. The problem with inserting these technologies is that 
considerable ground work must be done to develop the actual human knowledge or 
wisdom that makes them viable. However, additional future gains could be made from 
these technologies if started now. The researcher estimates that these systems could be in 
place in two to four years from start date. 

3. Evolving Processes 

As seen in Chapter IV, many of the IT solutions the Government undertakes will 
most likely fail or cost considerably more than anticipated while not producing the 
productivity enhancements being sought. Of the many reasons previously expressed for 
this failure, it is the researcher’s opinion that much of it has to do with how these systems 
are evolved. Typically, one of two things occur. An IT system is bought for an 
organization, or group of organizations, that will supposedly solve all of their productivity 
problems. An example of this would be the various purchasing systems such as SACONS, 
or APADE. The other end of the spectrum is that individual offices within several 
organizations will develop their own unique solutions to IT problems (Appendix B). 
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Neither of these approaches will work if IT is to be successfully applied to solve process 

problems, and increase productivity substantially. An new approach must be developed. 

The approach suggested by the researcher is to identify a particular program 

management office within a major systems command as a test laboratory. Here a 

redesigned procurement process would be prototyped using IT in the manner described in 

Chapter VI. A comparable or similar procurement could be done in a traditional manner 

to serve as a benchmark for the test lab. In this controlled environment, metrics could be 

easily established and data collected. Subsequent trials could be used to refine, or 

“tweek,” the system to achieve the greatest process improvement. When the system has 

proven itself, and the process is well defined, it could then be exported to similar offices. 
If it subsequently fails, then the damage has been contained to one area and is not as 

intolerably expensive as some of our more noticeable IT failures today. 

C. RECOMMENDED AREAS FOR FUTURE FOR STUDY 

The application of business process reengineering to acquisition processes is an 
area ripe for study. Little work has been done in this area, but it will undoubtedly receive 
more attention in the future. This is because it is the only way to achieve the dramatic 
improvements in time and money that will be required in the future. As pointed out in 
Chapter III, other improvements have not dramatically improved the business cycle times 
or cost elements. As more acquisition professionals realize the potency of reengineering 
principles, increased attention will be focused on this area. 

Some recommendations for future study include: 
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1. A detailed study of the development of an Acquisition Plan within a major 
systems command. 

2. The relative importance of various IT tools in reducing cycle times within a 
given acquisition area or process. 

3. The use of workflow software in defining acquisition processes. 

4. The definition of all the major processes within a major systems command. 

D. CONCLUSIONS 

It has been the researcher’s intent to wave the flag; the red flag. We are at a 
critical cusp in the world of acquisition reform. Much good work has been done before us 
by a long line of acquisition professionals and organizations. However, the increases in 
productivity and reductions in cycle time required in the future will be even more dramatic 
than today. In the near term, decisions may have to be made to trade off acquisition 
overhead for warfighting assets. The strategic employment of information technology will 
make these decisions much more bearable. Accomplishing a reduction in cycle times 
through IT will also allow us to get the latest technology in the hands of those warfighters 
even sooner than we already do. 
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APPENDIX A - WRITTEN AP ELEMENTS (FAR PART 7) 



(a) Acquisition background and objectives. 

(1) Statement of need . 

(2) Applicable conditions. 

(i) requirements for compatibility with existing or future systems or 

programs and 

(ii) any known cost, schedule, and capability or performance 
constraints. 

(3) Cost. 

(i) Life-cycle cost. 

(ii) Design-to-cost. 

(iii) Application of should-cost. 

(4) Capability or performance. 

(5) Delivery or performance-period requirements 

(6) Trade-offs 

(7) Risks (technical, cost, and schedule) 

(8) Acquisition streamlining. 



(b) 



Plan of action: 

(1) Sources. 

(2) Competition. 

(3) Source-selection procedures. 

(4) Contracting considerations. 

(5) Budgeting and funding. 

(6) Product descriptions. 

(7) Priorities, allocations, and allotments. 

(8) Contractor versus Government performance. 

(9) Inherently governmental functions. 

(10) Management information requirements . 

(11) Make or buy. 

(12) Test and evaluation. 

(13) Logistics considerations. 

(14) Government-furnished property. 

(15) Government-furnished information. 

( 1 6) Environmental and energy conservation objectives. 

(17) Security considerations. 

(18) Other considerations. 

(19) Milestones for the acquisition cycle: 

Acquisition plan approval. 

Statement of work. 

Specifications. 
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Data requirements. 

Completion of acquisition-package preparation. 

Purchase request. 

Issuance of synopsis. 

Issuance of solicitation. 

Evaluation of proposals, audits, and field reports. 

Beginning and completion of negotiations. 

Contract preparation, review, and clearance. 

Contract award. 

(20) Identification of participants in acquisition plan preparation. 
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APPENDIX B - ACQUISITION SOFTWARE SURVEY 



As of 21 February 1997. 

Acquisition Center's Executive System (ACES ) 

Acquisition Professional (AcqPro 1.6) 

Acquisition Tracking Tool (ACQTRACK 1.0) 

AEGIS Document Imaging System (ADIS) 

Air Force Acquisition Model (AFAM) 

Air Force Medical Acquisition Model (AFMAM) 

Analysis Product (Archer 1.0) 

Artillery Systems Analysis Product (Battleaxe 1.0) 

ASC Source Selection Application (EZSource 1.1) 

Automated CDRL and Tracking System (ACTS) 

Automated Cost Estimating Integrated Tools (ACEIT 2.3) 

Automated Data Management System (ADMS 4.0) 

Automated Information Retrieval System (AIRS/PDM) 

Automated Lesson Learned Capture and Retrieval System (ALLCARS) 
Automated Test Planning System (ATPS) 

Automation of Procurement and Accounting Data Entry System (APADE) 
Biweekly Indicator Tracking System (BITS 2.02) 

Budget/Readiness Analysis Technique (BRAT 3.0) 

Commerce Business Daily-Synopsis (CBD-Syn v. 1.7.2) 

Computer Resources Information Base (CRIB) 

Computer Resources Life Cycle Management Plan (CRLCMP) 

Computer. Opt. Mod. Predicting/ Analyzing Support/Structure (COMPASS 2.0a) 
Conformer (Conformer 2.1) 

Consolidation Risk Assessment Methodology (CORAM 3.2) 

Contract Action Tracking System (CATS 2.0) 

Contract Appraisal System Module (CAPPS 2.2) 

Contract Data Requirements List (CDRL) 

Contract Monitoring Automated System (CMAS 1 .2) 

Contracts Information Management System (CEMS 3.0) 

Correlation Calculator for Cost-Risk Analysis (C-RISK 3.0) 

Cost Analysis Decision Support System (CADSS 2.0) 

Data Management System (DMS 5.25) 

Distributed INFOSEC Accounting System (DIAS) 

Early Warning System (EWS No Ver #) 

EDI Watch! (EDI Watch N/A) 

Electronic Personnel Security Questionnaire (EPSQ) 

Federal Acquisition Regulations Automated (FARA 6.0) 

Financial Management & Execution System (FMETS 4.3) 
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Force Cost Model (FCM 96.0) 

Formal Risk Analysis (FRISK 3.2) 

Fuzzy Logic Applied to Risk Evaluation (FLARE ) 

Helicopter Analysis Product (Leonardo 1.0) 

Integrated CDRL and Routing System (ICARS) 

Integrated Management Information System (IMIS ) 

Joint Advanced Strike Technology Operating and Support Technology Evaluation Model (JOSTE 
1 . 0 ) 

Joint Modeling and Simulation System (J-MASS) 

Joint Services Cost Oriented Resource Estimating (JCORE) Model (JCORE 1.42) 

LAN Integration and Network Kemal (LINK (TM) 1.2) 

Litigation Support Data Base (LSDB 3.5.21) 

Logisitcs Planning and Requirements Systems (LOGPARS 3.1) 

Louis Link and Louis II (LOUIS 2.38) 

Maritime Patrol Aircraft Analysis Product (Pegasus 1.1) 

Master Acquisition Program Plan (MAPP) 

Merged Obligation and Liquidation Tracking System (MOLTS 1.1) 

Military Specifications and Standards Data Repository (MILSPEC 1.1) 

Modernized Parts Control Automated Support System (MPCASS) 

Multi-User Engineering Change Proposal Automated Review System (MEARS) 

Naval Aviation Lessons Learned (NALL No Vers #) 

Operating and support Management Information System (OSMIS FY95) 

Paragraph Analyzer (PARANA) 

Parametric Cost Estimating Relationship Module (PACER 2.0) 

Parametric Review of Information for Costing and Evaluation (PRICE PRICE S V2.ll, PRICE 
H/HL/M V3.0) 

Performance Analyzer for Windows (PA Win 1.2) 

Pre- Award Information Exchange System (PIXS 2.0) 

Process Analysis and Project Integrated Environment-Integrated Knowledge Environment (PAPIE- 
IKE 4.0) 

Procurement and Contracts Tracking System (PACTS 6.5) 

Procurement Contract Monitoring System (ProCMAS 3.0) 

Procurement Network (PROCNET) 

Procurement Request Information System Module (PRISM 6.4) 

Program Acquisition Management System (PAMS 1.12) 

Program Integration Scheduling and Management System/ARDEC (PRISM/ARDEC 3.0) 

Program Management Automated Data System (PMADS 1.0) 

Program Manager's Workstation (PMWS) 

Proposal Evaluation tool (PET 1.1) 

Purchase Request Entry Module (PREM 6.4) 

Reliability and Maintainability Logistics (RAMLOG No Vers #) 

Requisition Automated Processing System (RAPS) 

Resource Analysis Decision Support System (RADSS 5.3) 
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RFP Guidelines (RFPGUIDE5) 

Satellite Communications Management Information System (SCMIS 3.1) 
Security Information Management System (SIMS) 

Security Management System (SecurTrac 1.0) 

Shared Program Information Network (SPINE ) 

Software Specification Assistant (SSA 3.4) 

Specification Trainer-Editor (SpecTrE) 

Supply Automated Management System (SAMS) 

System Evaluation and Estimation of Resources (SEER) 

Team Work Plan (TWP) 

Turbo Streamliner (TURBO 1.0) 
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APPENDIX C - PLANS SUBSUMED BY THE MAPP 



Source: NAVSEA Master Acquisition Planning Program Handbook 



1. Acquisition Plan 

2. Computer Resources Integrated Support 

3. Computer Resources Life-Cycle 
Management Plan 

4. Configuration Audit Plan 

5. Configuration Plan 

6. Continuous Acquisition and Life-Cycle 
Support (CALS) Implementation Plan 

7. Depot Planning Annex 

8. Electromagnetic Compatibility Program Plan 

9. Electromagnetic Interference Control Plan 

10. Electrostatic Discharge Control Program Plan 

11. Engineering Change Proposal System Safety 
Report 

12. Engineering Data Management Plan 

13. Equipment Facilities Requirements Plan 

14. Facilities Requirements Plan 

15. Facilities Requirements Report 

16. Failure Modes Effects and Criticality Plan 

17. Government Concept of Operation (CALS) 

18. Hardness Assurance, Maintenance, and 
Surveillance Plans 

19. Hardness Surveillance Plan 

20. Human Engineering Dynamic Simulation 
Plan 

21. Human Engineering Program Plan 

22. Human Systems Integration Plan 

23. Implementation Plan 

24. Integrated Logistic Support Plan 

25. Integrated Support Plan 

26. Interface Requirements Specification 

27. Interim Contractor Supply Support 
Management Plan Report 

28. Interim Contractor Support Plan 

29. Interim Support Plan 

30. Level of Repair Program Plan 

3 1 . Logistic Support Analysis Plan 

32. Logistics Requirements Funding Summary 

33. Logistics Support Analysis Plan 

34. Logistics Support Analysis Use Study 

35. Maintenance Plan 

36. Manpower, Personnel, and Training (MPT) 
Concept Document 

37. Military Characteristics Document 

38. MPT Resources Requirements Document 



39. Navy Training Plan 

40. Nuclear Hardness and Survivability Program 
Plan 

41. Nuclear, Biological, and Chemical 
Contamination Survivability Assurance Plan 

42. Operation Requirements Document 

43. Operations Support Plan 

44. Packaging Management Plan 

45. Packaging, Handling, Storage, and 
Transportation Program Plan 

46. Phased Support Plan 

47. Post Production Support Plan 

48. Program Protection Implementation Plan 

49. Quality Assurance Program Plan 

50. Radar Spectrum Management Control Plan 

5 1 . Real-Time Outfitting Management 
Information Systems Management Plan 

52. Reliability and Maintainability Program Plan 

53. Risk Management Plan 

54. Safety Studies Plan 

55. Site Evaluation Report 

56. Software Development Plan 

57. Software Quality Program Plan 

58. Software Support Transition Plan 

59. Standardization Accomplishment Report 

60. Standardization Program Plan 

6 1 . Supply Support Management Plan 

62. Support Site Activation Plan 

63. Supportability Assessment Plan 

64. System Safety Hazard Analysis Report 

65. System Safety Program Plan 

66. Technical Data Acquisition Plan 

67. Technical Data Management Plan 

68. Technical Manual Organization Plan 

69. Technical Manual Plan 

70. Technical Manual Publication Plan 

71. Technical Manual Quality Assurance 
Program Plan 

72. Technical Manual Schedules and Status 
Report 

73. Technical Manual Validation Plan 

74. Technical Manual Verification Plan 

75. Test and Evaluation Master Plan 

76. Test and Evaluation Program Plan 

77. Testability Program Plan 
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78. Training Device Requirements Document 

79. Training Effectiveness Evaluation Plan 

80. Training Equipment Requirements Document 

81. Training Facilities Report 

82. Training Systems Alternative Report 

83. Transition Plan 

84. Transportation Plan 



85. User’s Logistics Support Summary 

86. Verification, Demonstration, and Evaluation 
Plan 

87. Version Description Document 

88. Waiver or Deviation Safety Report 

89. Weapon System and Equipment Transition 
Plan 



Note: Plans in bold type are required by DoD/DoN 5000 series instructions. 

Note: Many of the incorporated plans have duplicate titles. The total number of plans subsumed in the 
current version of MAPP is 10 1 . 
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APPENDIX D -NAVAIR PROCUREMENT PROCESS 



BRIEF OVERVIEW OF 
PROCUREMENT PROCESS 
FORA 

MAJOR SOLICITATION 



Program Manager (PM) 
Identifies Requirement 

* 



PM Ontlines Schednle, 
Related Procurements, 
Obtains Procurement Number, 
and Enters Data into PMIS 



PM Defines 
Procurement Team 






PM / AIR-05 / AIR-04 / AIR-02 
•Statement of Work (SOW) 
•Specifications 

•System Security Engineering 
Implications for SOW / Specs 
(see AIR-546 & 07T3 
•Sections B-H, J 

•Contract Data Requirements List 
(CDRL) 

•DD254 (Cog Engineer may reqnire 
AIR 07T3 Assistance 
•Cost Analysis Requirements 
•Acqnisition Plan Lnpnts 
•Tech Data (mannals & drawings 



PM Issues 

Reqnirements Letter 



PM Convenes PPC to 
Discnss Strategv/Issnes 



PM Issnes PPA w/Updates 
as needed to show 
Prog/Mission Changes 
and m afatajn ? £MI£ data 



NO 

e.g.. 

Small procurement 
Few personnel on team 
Specifications are complete 




PM / AIR-02 / AIR-OOC 

•Synopsis 

•J&A 

•Sections H - M 
•Legal Review 
•Acqnisition Plan inpnts 



ALL MEMBERS OF TEAM 
•When applicable, prepare source 
selection plan, and Sections K,L,M 
•Draft Contract Line Item structure 



Develop Sub-Team 
Structure & Assignments 



Large team composition 
Considerable matrix 
involvement 


Sub-Teams &PM Review Draft 
Solicitations, Perform DRRB 
Fnnction & Sign CDRLs 


V 


"T 



Procurement Team Prepares 
Draft Solicitation in Gronp 
Sessions & Performs DRRB 
Function and Sign CPRLs 



AIR-08 Review SOW 
to Validate Proper nse 
of Fnnding Type 



A. 



PCO 

Issues Synopsis 



■f 



PM or Designee Rontes Draft 
Solicitation to AIR-07T3 & 
AIR-7133 for Tech Secnrity, 
Acq Protection, & AIS Review 



Team issues Draft Solicitation 
to Indnstry for comments & 
AIR-02 issnes draft document 

31 



Team: 
at Reviews Comments 

b) Responds to All Comments 
via PCO 

c) Incorporates Applicable 
Changes to I^aft Solicitation 




e.g.. 

Major competition 
Ample obligation time 
Many unknowns in specs 
Need streamlining assistance 
Questions on vendor base 



Proc Team Review Final Solicitation 
& Obtains Signature on Cover Page 



Solicitation Release * | 



NO 



e-g.. 

Insufficient Time 
Well defined specs 
Follow on buy 



* Note: For competitive NAVAIRHQ 
solicitations, SSA approval 
is reqnired. 
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APPENDIX E - NAVAIR AP PROCESS 



PEO (A) and PEO(T) ACQUISITION PLAN 
PREPARATION AND APPROVAL PROCESS 



PHASE I 
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